On 2018-03-09 09:47:16 [+0000], Roosen Henri wrote: > > maybe #0 and #1 are idle but #2 and #3 should make progress. #2 looks > > like a warning, do you know where it is from or is this everything > > you > > get? Unless the warning comes from an atomic context you should see > > something on the UART. > > #2 and #3 were not making progress, they kept on spinning at the > arch_spin_lock(). It looks like those two are different locks. So someone should own it (and be running) and unlock once done. > > > Some things I found out by testing on v4.9: > > > - minimum test to reproduce problem "while true; do hackbench -g > > > 100 -l > > > 1000; done &" > > > - reproducible with "hackbench -T" (threads) > > > - reproducible only on iMX6Q, not (yet) on iMX6S, iMX6D > > > - NOT reproducible with "hackbench -p" (pipes) |Running in process mode with 100 groups using 40 file descriptors each (== 4000 tasks) |Each sender will pass 1000 messages of 100 bytes |Time: 552.224 |Running in process mode with 100 groups using 40 file descriptors each (== 4000 tasks) |Each sender will pass 1000 messages of 100 bytes |Signal 2 caught, longjmp'ing out! |longjmp'ed out, reaping children |sending SIGTERM to all child processes |signaling 4000 worker threads to terminate |^C^CTime: 476.063 |~# uptime | 19:50:19 up 6 days, 4:11, 1 user, load average: 0.01, 0.01, 0.10 This survived 6 days. It was challenging to cancel hackbench because it was running via ssh in a screen session and I was loosing my network connection due to inactivity… > Thanks, > Henri Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
