On 02/11/15 15:25, Richard Weinberger wrote: > Am 02.11.2015 um 15:30 schrieb Anton Ivanov: >> On 02/11/15 10:01, Richard Weinberger wrote: >>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov: >>>> [snip] >>>> >>>>>>> I'm pretty sure that you don't see the issue as your Jessy userspace >>>>>>> uses nanosleep periodically. >>>>>> There are quite a few things running so this may indeed be the case. >>>>>> >>>>>> What do you use for userspace (so I can try to reproduce this and debug >>>>>> it)? >>>>> Debian Squeeze amd64 with almost nothing running. >>>>> >>>>> PID TTY STAT TIME COMMAND >>>>> 2 ? S 0:00 [kthreadd] >>>>> 3 ? S 0:00 \_ [ksoftirqd/0] >>>>> 4 ? S 0:00 \_ [kworker/0:0] >>>>> 5 ? S< 0:00 \_ [kworker/0:0H] >>>>> 6 ? S 0:00 \_ [kworker/u2:0] >>>>> 7 ? S 0:00 \_ [kdevtmpfs] >>>>> 8 ? S< 0:00 \_ [netns] >>>>> 9 ? S< 0:00 \_ [writeback] >>>>> 10 ? S 0:00 \_ [kworker/u2:1] >>>>> 11 ? S< 0:00 \_ [crypto] >>>>> 12 ? S 0:00 \_ [kworker/0:1] >>>>> 13 ? S< 0:00 \_ [bioset] >>>>> 14 ? S< 0:00 \_ [kblockd] >>>>> 15 ? S 0:00 \_ [kswapd0] >>>>> 68 ? S 0:00 \_ [fsnotify_mark] >>>>> 221 ? S< 0:00 \_ [bioset] >>>>> 229 ? S< 0:00 \_ [deferwq] >>>>> 231 ? S 0:00 \_ [jbd2/ubda-8] >>>>> 232 ? S< 0:00 \_ [ext4-rsv-conver] >>>>> 233 ? S< 0:00 \_ [kworker/0:1H] >>>>> 1 ? Ss 0:00 init [2] >>>>> 271 ? S<s 0:00 udevd --daemon >>>>> 297 ? S< 0:00 \_ udevd --daemon >>>>> 298 ? S< 0:00 \_ udevd --daemon >>>>> 549 ? Sl 0:00 /usr/sbin/rsyslogd -c4 >>>>> 580 ? Ss 0:00 /usr/sbin/cron >>>>> 595 ? Ss 0:00 /usr/bin/dbus-daemon --system >>>>> 609 ? Ss 0:00 /usr/sbin/sshd >>>>> 628 tty0 Ss 0:00 /bin/login -- >>>>> 631 tty0 S 0:00 \_ -bash >>>>> 636 tty0 R+ 0:00 \_ ps fax >>>>> 629 tty1 Ss+ 0:00 /sbin/getty 38400 tty1 linux >>>>> 630 ttyS0 Ss+ 0:00 /sbin/getty 115200 ttyS0 linux >>>> I cannot reproduce that by dropping jessie into single user mode so I am >>>> going to build a squeeze image and re-test with that. >>> I can also reproduce using init=/bin/bash. >> Reproduced, I think I located the culprit. >> >> We still need to relay the "interruption" signal which broke a nanosleep. >> >> I am testing a fix, which so far is working. If the fix proves viable, I >> will test it as above (init=/bin/bash) and the normal tests I usually do >> anyway. >> >> If it works OK, I will submit v4. > Yay!
Apologies for that. A few years back I found that I can mask most of the races which this patch is trying to address by pinning to a single CPU. As a result most of my test scripts have a taskset -c 0 in them. The revised version where we restore the relay of nanosleep interruptions checks out for me, I just re-submitted it. I will rebase my ubd patches on top of that and once they work, submit them as well. A. > > Thanks, > //richard the QA engineer ;) > ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
