Patch/shigeru work/release embedded boards #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 9 commits
February 25, 2019 01:19
bsd-hacker
pushed a commit
that referenced
this pull request
May 28, 2019
It appeared that using NET_EPOCH_WAIT() while holding global BPF lock can lead to another panic: spin lock 0xfffff800183c9840 (turnstile lock) held by 0xfffff80018e2c5a0 (tid 100325) too long panic: spin lock held too long ... #0 sched_switch (td=0xfffff80018e2c5a0, newtd=0xfffff8000389e000, flags=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2133 #1 0xffffffff80bf9912 in mi_switch (flags=256, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:439 #2 0xffffffff80c21db7 in sched_bind (td=<optimized out>, cpu=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2704 #3 0xffffffff80c34c33 in epoch_block_handler_preempt (global=<optimized out>, cr=0xfffffe00005a1a00, arg=<optimized out>) at /usr/src/sys/kern/subr_epoch.c:394 #4 0xffffffff803c741b in epoch_block (global=<optimized out>, cr=<optimized out>, cb=<optimized out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:416 #5 ck_epoch_synchronize_wait (global=0xfffff8000380cd80, cb=<optimized out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:465 #6 0xffffffff80c3475e in epoch_wait_preempt (epoch=0xfffff8000380cd80) at /usr/src/sys/kern/subr_epoch.c:513 #7 0xffffffff80ce970b in bpf_detachd_locked (d=0xfffff801d309cc00, detached_ifp=<optimized out>) at /usr/src/sys/net/bpf.c:856 #8 0xffffffff80ced166 in bpf_detachd (d=<optimized out>) at /usr/src/sys/net/bpf.c:836 #9 bpf_dtor (data=0xfffff801d309cc00) at /usr/src/sys/net/bpf.c:914 To fix this add the check to the catchpacket() that BPF descriptor was not detached just before we acquired BPFD_LOCK(). Reported by: slavash Tested by: slavash MFC after: 1 week git-svn-id: svn+ssh://svn.freebsd.org/base/head@348324 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
bsd-hacker
pushed a commit
that referenced
this pull request
May 28, 2019
It appeared that using NET_EPOCH_WAIT() while holding global BPF lock can lead to another panic: spin lock 0xfffff800183c9840 (turnstile lock) held by 0xfffff80018e2c5a0 (tid 100325) too long panic: spin lock held too long ... #0 sched_switch (td=0xfffff80018e2c5a0, newtd=0xfffff8000389e000, flags=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2133 #1 0xffffffff80bf9912 in mi_switch (flags=256, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:439 #2 0xffffffff80c21db7 in sched_bind (td=<optimized out>, cpu=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2704 #3 0xffffffff80c34c33 in epoch_block_handler_preempt (global=<optimized out>, cr=0xfffffe00005a1a00, arg=<optimized out>) at /usr/src/sys/kern/subr_epoch.c:394 #4 0xffffffff803c741b in epoch_block (global=<optimized out>, cr=<optimized out>, cb=<optimized out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:416 #5 ck_epoch_synchronize_wait (global=0xfffff8000380cd80, cb=<optimized out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:465 #6 0xffffffff80c3475e in epoch_wait_preempt (epoch=0xfffff8000380cd80) at /usr/src/sys/kern/subr_epoch.c:513 #7 0xffffffff80ce970b in bpf_detachd_locked (d=0xfffff801d309cc00, detached_ifp=<optimized out>) at /usr/src/sys/net/bpf.c:856 #8 0xffffffff80ced166 in bpf_detachd (d=<optimized out>) at /usr/src/sys/net/bpf.c:836 #9 bpf_dtor (data=0xfffff801d309cc00) at /usr/src/sys/net/bpf.c:914 To fix this add the check to the catchpacket() that BPF descriptor was not detached just before we acquired BPFD_LOCK(). Reported by: slavash Tested by: slavash MFC after: 1 week
added 19 commits
July 5, 2019 01:42
added 12 commits
July 20, 2019 08:57
bsd-hacker
pushed a commit
that referenced
this pull request
Aug 16, 2019
…two) This commit is mostly a nop, but ends up renumbering #4 clause to #3 in one copy of quad.h... this is OK; stand/ situation in stable/11 is pretty murky and the commit that renumbered the clause got lost somewhere. quad.h will be disappearing in a not-so-distant future MFC. r351078: stand: kick out quad.h Use quad.h from libc instead for the time being. This reduces the number of nearly-identical-quad.h we have in tree to two with only minor changes. Prototypes for some *sh*di3 have been added to match the copy in libkern. The differences between the two are likely few enough that they can perhaps be merged with little additional effort to bring us down to 1. r351085: libc quad.h: one last _STANDALONE correction r351088: Revert r351078, r351085: stand/quad.h eviction It did not go well; further examination is required...
bsd-hacker
pushed a commit
that referenced
this pull request
Aug 16, 2019
…two) This commit is mostly a nop, but ends up renumbering #4 clause to #3 in one copy of quad.h... this is OK; stand/ situation in stable/11 is pretty murky and the commit that renumbered the clause got lost somewhere. quad.h will be disappearing in a not-so-distant future MFC. r351078: stand: kick out quad.h Use quad.h from libc instead for the time being. This reduces the number of nearly-identical-quad.h we have in tree to two with only minor changes. Prototypes for some *sh*di3 have been added to match the copy in libkern. The differences between the two are likely few enough that they can perhaps be merged with little additional effort to bring us down to 1. r351085: libc quad.h: one last _STANDALONE correction r351088: Revert r351078, r351085: stand/quad.h eviction It did not go well; further examination is required...
bsd-hacker
pushed a commit
that referenced
this pull request
Dec 29, 2019
With WITNESS enabled we see the following warning:
lock order reversal: (sleepable after non-sleepable)
1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @
/usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297
2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @
/usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137
stack backtrace:
#0 0xffffffc0002a579e at witness_checkorder+0xb72
#1 0xffffffc0002a5556 at witness_checkorder+0x92a
#2 0xffffffc000254c7a at _sx_slock_int+0x66
#3 0xffffffc00025537a at _sx_slock+0x8
#4 0xffffffc000123022 at clk_get_freq+0x38
#5 0xffffffc0005463e4 at __clzdi2+0x2bb8
#6 0xffffffc00014af58 at randomdev_getkey+0x76e
#7 0xffffffc0001278b0 at simplebus_add_device+0x7ee
#8 0xffffffc00027c9a8 at device_attach+0x2e6
#9 0xffffffc00027c634 at device_probe_and_attach+0x7a
#10 0xffffffc00027d76a at bus_generic_attach+0x10
#11 0xffffffc00014aab0 at randomdev_getkey+0x2c6
#12 0xffffffc00027c9a8 at device_attach+0x2e6
#13 0xffffffc00027c634 at device_probe_and_attach+0x7a
#14 0xffffffc00027d76a at bus_generic_attach+0x10
#15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52
#16 0xffffffc000278b3e at config_intrhook_establish+0x146
#17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe
The clock topology lock can sleep, which means we cannot attempt to
acquire it while holding the non-sleepable mutex.
Fix that by retrieving the clock speed once, during attach and not every
time during SPI transaction setup.
Submitted by: kp
Sponsored by: Axiado
bsd-hacker
pushed a commit
that referenced
this pull request
Jul 6, 2020
Add a more compact display format for kern.tty_info_kstacks inspired by procstat -kk. Set it as a default one. # sysctl kern.tty_info_kstacks=1 kern.tty_info_kstacks: 0 -> 1 # sleep 2 ^T load: 0.17 cmd: sleep 623 [nanslp] 0.72r 0.00u 0.00s 0% 2124k #0 0xffffffff80c4443e at mi_switch+0xbe #1 0xffffffff80c98044 at sleepq_catch_signals+0x494 #2 0xffffffff80c982c2 at sleepq_timedwait_sig+0x12 #3 0xffffffff80c43af3 at _sleep+0x193 #4 0xffffffff80c50e31 at kern_clock_nanosleep+0x1a1 #5 0xffffffff80c5119b at sys_nanosleep+0x3b #6 0xffffffff810ffc69 at amd64_syscall+0x119 #7 0xffffffff810d5520 at fast_syscall_common+0x101 sleep: about 1 second(s) left out of the original 2 ^C # sysctl kern.tty_info_kstacks=2 kern.tty_info_kstacks: 1 -> 2 # sleep 2 ^T load: 0.24 cmd: sleep 625 [nanslp] 0.81r 0.00u 0.00s 0% 2124k mi_switch+0xbe sleepq_catch_signals+0x494 sleepq_timedwait_sig+0x12 sleep+0x193 kern_clock_nanosleep+0x1a1 sys_nanosleep+0x3b amd64_syscall+0x119 fast_syscall_common+0x101 sleep: about 1 second(s) left out of the original 2 ^C Suggested by: avg Reviewed by: mjg Relnotes: yes Sponsored by: Mysterious Code Ltd. Differential Revision: https://reviews.freebsd.org/D25487
bsd-hacker
pushed a commit
that referenced
this pull request
Aug 22, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
create SD images for arm64 boards.