Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Best wrote: > On Sun Apr 15 12, Alexander Leidinger wrote: > > On Sat, 14 Apr 2012 22:47:46 +0200 Alexander Leidinger > > wrote: > > > > > On Sat, 14 Apr 2012 20:32:56 + Alexander Best > > > wrote: > > > > > > > On Sat Apr 14 12, Alexander Leidinger wrote: > > > > > On Fri, 13 Apr 2012 20:32:22 + Alexander Best > > > > > wrote: > > > > > > > > > > > i'm having problems with the patch. beforehand, playing music > > > > > > from www.mixcloud.com worked. now the flash based player is > > > > > > initialising forever. > > > > > > > > > > > just drop me a note with exact instructions and i can give you > > > > > > more verbose information or debugging stats. again: this issue > > > > > > might be futex related and not a result of your patch. > > > > > > > > > > Are you running -current? If yes I Looks try to get some time to > > > > > commit the linuxulator-dtrace probes, now that SDT probes can be > > > > > loaded dynamically there is no risk to panic the system when the > > > > > linuxulator is loaded after boot and dtrace is used. This could > > > > > help looking at problems with locks. > > > > > > > > yes i'm running a very recent HEAD on amd64. > > > > > > I'm in the process of merging all the new stuff from HEAD into my SVN > > > branch. With a slow system and a slow line this may take a while. I > > > hope to at least update my branch in SVN > > > (users/netchild/linuxulator-dtrace) today. I don't know if I get the > > > time to merge it to HEAD today. > > > > Hmmm... do I remember correctly that I already gave a dtrace patch to > > you to check for futex problems? I think I changed the locking-probes > > since I gave the patch to you, but I'm not sure. Anyway, the patch > > against a recent -current is available from > > http://www.leidinger.net/FreeBSD/current-patches now. > > yeah you're right. i've applied the patch and compiled and installed the > kernel. i'm not very experienced with dtrace, so i'll need some instructions > on how to proceed. buildkernel suceeded, but i got this error during buildworld: /usr/github-freebsd-head/sys/modules/linux/../../compat/linux/linux_fork.c:33:10: fatal error: 'opt_kdtrace.h' file not found #include "opt_kdtrace.h" ^ 1 error generated. mkdep: compile failed alex > > cheers. > alex > > btw: i saw some of these warnings: > > ctfconvert -L VERSION -g ieee80211_sta.o > ERROR: ieee80211_sta.c: die 41029: failed to retrieve array bounds > > ...i hope their aren't anything to worry about. > > > > > Bye, > > Alexander. > > > > -- > > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > On Sat, 14 Apr 2012 22:47:46 +0200 Alexander Leidinger > > > wrote: > > > > > > > On Sat, 14 Apr 2012 20:32:56 + Alexander Best > > > > wrote: > > > > > > > > > On Sat Apr 14 12, Alexander Leidinger wrote: > > > > > > On Fri, 13 Apr 2012 20:32:22 + Alexander Best > > > > > > wrote: > > > > > > > > > > > > > i'm having problems with the patch. beforehand, playing music > > > > > > > from www.mixcloud.com worked. now the flash based player is > > > > > > > initialising forever. > > > > > > > > > > > > > just drop me a note with exact instructions and i can give you > > > > > > > more verbose information or debugging stats. again: this issue > > > > > > > might be futex related and not a result of your patch. > > > > > > > > > > > > Are you running -current? If yes I Looks try to get some time to > > > > > > commit the linuxulator-dtrace probes, now that SDT probes can be > > > > > > loaded dynamically there is no risk to panic the system when the > > > > > > linuxulator is loaded after boot and dtrace is used. This could > > > > > > help looking at problems with locks. > > > > > > > > > > yes i'm running a very recent HEAD on amd64. > > > > > > > > I'm in the process of merging all the new stuff from HEAD into my SVN > > > > branch. With a slow system and a slow line this may take a while. I > > > > hope to at least update my branch in SVN > > > > (users/netchild/linuxulator-dtrace) today. I don't know if I get the > > > > time to merge it to HEAD today. > > > > > > Hmmm... do I remember correctly that I already gave a dtrace patch to > > > you to check for futex problems? I think I changed the locking-probes > > > since I gave the patch to you, but I'm not sure. Anyway, the patch > > > against a recent -current is available from > > > http://www.leidinger.net/FreeBSD/current-patches now. > > > > yeah you're right. i've applied the patch and compiled and installed the > > kernel. i'm not very experienced with dtrace, so i'll need some instructions > > on how to proceed. > > buildkernel suceeded, but i got this error during buildworld: it seems your patch breaks building world with MODULES_WITH_WORLD defined. when modules get buildduring buildkernel, i don't see that error. cheers. alex > > /usr/github-freebsd-head/sys/modules/linux/../../compat/linux/linux_fork.c:33:10: > fatal error: 'opt_kdtrace.h' file not found > #include "opt_kdtrace.h" > ^ > 1 error generated. > mkdep: compile failed > > alex > > > > > cheers. > > alex > > > > btw: i saw some of these warnings: > > > > ctfconvert -L VERSION -g ieee80211_sta.o > > ERROR: ieee80211_sta.c: die 41029: failed to retrieve array bounds > > > > ...i hope their aren't anything to worry about. > > > > > > > > Bye, > > > Alexander. > > > > > > -- > > > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > > > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun, 15 Apr 2012 11:23:08 + Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > > On Sun Apr 15 12, Alexander Best wrote: > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > On Sat, 14 Apr 2012 22:47:46 +0200 Alexander Leidinger > > > > wrote: > > > > > > > > > On Sat, 14 Apr 2012 20:32:56 + Alexander Best > > > > > wrote: > > > > > > > > > > > On Sat Apr 14 12, Alexander Leidinger wrote: > > > > > > > On Fri, 13 Apr 2012 20:32:22 + Alexander Best > > > > > > > wrote: > > > > > > > > > > > > > > > i'm having problems with the patch. beforehand, playing > > > > > > > > music from www.mixcloud.com worked. now the flash based > > > > > > > > player is initialising forever. > > > > > > > > > > > > > > > just drop me a note with exact instructions and i can > > > > > > > > give you more verbose information or debugging stats. > > > > > > > > again: this issue might be futex related and not a > > > > > > > > result of your patch. > > > > > > > > > > > > > > Are you running -current? If yes I Looks try to get some > > > > > > > time to commit the linuxulator-dtrace probes, now that > > > > > > > SDT probes can be loaded dynamically there is no risk to > > > > > > > panic the system when the linuxulator is loaded after > > > > > > > boot and dtrace is used. This could help looking at > > > > > > > problems with locks. > > > > > > > > > > > > yes i'm running a very recent HEAD on amd64. > > > > > > > > > > I'm in the process of merging all the new stuff from HEAD > > > > > into my SVN branch. With a slow system and a slow line this > > > > > may take a while. I hope to at least update my branch in SVN > > > > > (users/netchild/linuxulator-dtrace) today. I don't know if I > > > > > get the time to merge it to HEAD today. > > > > > > > > Hmmm... do I remember correctly that I already gave a dtrace > > > > patch to you to check for futex problems? I think I changed the > > > > locking-probes since I gave the patch to you, but I'm not sure. > > > > Anyway, the patch against a recent -current is available from > > > > http://www.leidinger.net/FreeBSD/current-patches now. > > > > > > yeah you're right. i've applied the patch and compiled and > > > installed the kernel. i'm not very experienced with dtrace, so > > > i'll need some instructions on how to proceed. > > > > buildkernel suceeded, but i got this error during buildworld: > > it seems your patch breaks building world with MODULES_WITH_WORLD > defined. when modules get buildduring buildkernel, i don't see that > error. opt_kdtrace.h is generated by config. I've never used MODULES_WITH_WORLD, so I have no idea how this case is handled. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Leidinger wrote: > On Sun, 15 Apr 2012 11:23:08 + Alexander Best > wrote: > > > On Sun Apr 15 12, Alexander Best wrote: > > > On Sun Apr 15 12, Alexander Best wrote: > > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > > On Sat, 14 Apr 2012 22:47:46 +0200 Alexander Leidinger > > > > > wrote: > > > > > > > > > > > On Sat, 14 Apr 2012 20:32:56 + Alexander Best > > > > > > wrote: > > > > > > > > > > > > > On Sat Apr 14 12, Alexander Leidinger wrote: > > > > > > > > On Fri, 13 Apr 2012 20:32:22 + Alexander Best > > > > > > > > wrote: > > > > > > > > > > > > > > > > > i'm having problems with the patch. beforehand, playing > > > > > > > > > music from www.mixcloud.com worked. now the flash based > > > > > > > > > player is initialising forever. > > > > > > > > > > > > > > > > > just drop me a note with exact instructions and i can > > > > > > > > > give you more verbose information or debugging stats. > > > > > > > > > again: this issue might be futex related and not a > > > > > > > > > result of your patch. > > > > > > > > > > > > > > > > Are you running -current? If yes I Looks try to get some > > > > > > > > time to commit the linuxulator-dtrace probes, now that > > > > > > > > SDT probes can be loaded dynamically there is no risk to > > > > > > > > panic the system when the linuxulator is loaded after > > > > > > > > boot and dtrace is used. This could help looking at > > > > > > > > problems with locks. > > > > > > > > > > > > > > yes i'm running a very recent HEAD on amd64. > > > > > > > > > > > > I'm in the process of merging all the new stuff from HEAD > > > > > > into my SVN branch. With a slow system and a slow line this > > > > > > may take a while. I hope to at least update my branch in SVN > > > > > > (users/netchild/linuxulator-dtrace) today. I don't know if I > > > > > > get the time to merge it to HEAD today. > > > > > > > > > > Hmmm... do I remember correctly that I already gave a dtrace > > > > > patch to you to check for futex problems? I think I changed the > > > > > locking-probes since I gave the patch to you, but I'm not sure. > > > > > Anyway, the patch against a recent -current is available from > > > > > http://www.leidinger.net/FreeBSD/current-patches now. > > > > > > > > yeah you're right. i've applied the patch and compiled and > > > > installed the kernel. i'm not very experienced with dtrace, so > > > > i'll need some instructions on how to proceed. > > > > > > buildkernel suceeded, but i got this error during buildworld: > > > > it seems your patch breaks building world with MODULES_WITH_WORLD > > defined. when modules get buildduring buildkernel, i don't see that > > error. > > opt_kdtrace.h is generated by config. I've never used > MODULES_WITH_WORLD, so I have no idea how this case is handled. ahh ok. i've managed to get some stats via stats_timing.d. this is a snapshot during which a newly loaded tab in chromium was unresponsive for about 5 seconds. without the linux flash plugin running i never experienced such lock ups. i've attached the d-script stats. cheers. alex > > Bye, > Alexander. > > -- > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 otaku% sudo ./stats_timing.d ^C Number of calls per provider/application/kernel function: linuxulator32 npviewer.bin linux_schedtail 1 linuxulator32 npviewer.bin linux_set_robust_list 1 linuxulator32 npviewer.bin proc_init 1 linuxulator32 npviewer.bin linux_kernver 3 linuxulator32 npviewer.bin linux_get_osname 4 linuxulator32 npviewer.bin linux_get_osrelease 4 linuxulator32 npviewer.bin em_find 7 linuxulator32 npviewer.bin linux_get_prison 11 linuxulator32 npviewer.bin futex_atomic_op 335 linuxulator32
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Leidinger wrote: > On Sun, 15 Apr 2012 11:51:12 + Alexander Best > wrote: > > > ahh ok. i've managed to get some stats via stats_timing.d. this is a > > snapshot during which a newly loaded tab in chromium was unresponsive > > for about 5 seconds. without the linux flash plugin running i never > > experienced such lock ups. > > > > i've attached the d-script stats. > > What about the trace_futexes script and the two check_* scripts? The > stats show that there is a lot of work spend in the futexes. i'm having problems with those scripts. they have a negative impact on the linux processes. when i have the player at www.mixcloud.com running and run those scripts the music stops and the flash graphics get all distorted. here's some output from the trace_futexes.d script: otaku% sudo ./trace_futexes.d dtrace: 808 dynamic variable drops with non-empty dirty list dtrace: 833 failed speculations (available buffer(s) still busy) Stacktrace of last lock operation of the futex_mtx: kernel`linux_sys_futex+0xd34 kernel`ia32_syscall+0x299 kernel`0x805b05e5 Stacktrace of last lock operation of the futex_mtx: kernel`linux_sys_futex+0xd57 kernel`ia32_syscall+0x299 kernel`0x805b05e5 Stacktrace of last lock operation of the futex_mtx: kernel`linux_sys_futex+0xd57 kernel`ia32_syscall+0x299 kernel`0x805b05e5 ERROR: missing_access_check in linuxulator32:futex:futex_atomic_op kernel`ia32_syscall+0x299 kernel`0x805b05e5 dtrace: ERROR: open failed: No such file or directory `0x287b6533 Fatal error 'mutex is on list' at line 424 in file /usr/github-freebsd-head/lib/libthr/thread/thr_mutex.c (errno = 0) this is from the check_error.d script: otaku% sudo ./check_error.d ERROR: sleep_error in linuxulator32:futex:futex_sleep kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2a12800029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_wait kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2a12800029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_sleep kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2e94900029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_wait kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2e94900029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_sleep kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x30c4f00029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_wait kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x30c4f00029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_sleep kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2e94900029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_wait kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2e94900029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_sleep kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2a12800029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_wait kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x2a12800029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_sleep kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x30c4f00029d5fa5c ERROR: sleep_error in linuxulator32:futex:futex_wait kernel`ia32_syscall+0x299 kernel`0x805b05e5 0x287b6278 0x30c4f00029d5fa5c the check_internal_locks.d scripts seems to work fine. i think we talked about the failed-speculation-warnings beforehand and that they aren't critical: otaku% sudo ./check_internal_locks.d ^C Number of locks per type: otaku% sudo ./check_internal_locks.d dtrace: 42 failed speculations (available buffer(s) still busy) dtrace: 61 failed speculations (available buffer(s) still busy) dtrace: 183 failed speculations (available buffer(s) still busy) dtrace: 830 failed speculations (available buffer(s) still busy) dtrace: 893 failed speculations (available buffer(s) still busy) dtrace: 1489 failed speculations (available buffer(s) still busy) dtrace: 1546 failed speculations (available buffer(s) still busy) dtrace: 1208 failed speculations (available
Re: [PATCH] pipe2 for Linuxulator
On Sun, 15 Apr 2012 13:03:06 + Alexander Best wrote: > On Sun Apr 15 12, Alexander Leidinger wrote: > > On Sun, 15 Apr 2012 11:51:12 + Alexander Best > > wrote: > > > > > ahh ok. i've managed to get some stats via stats_timing.d. this > > > is a snapshot during which a newly loaded tab in chromium was > > > unresponsive for about 5 seconds. without the linux flash plugin > > > running i never experienced such lock ups. > > > > > > i've attached the d-script stats. > > > > What about the trace_futexes script and the two check_* scripts? The > > stats show that there is a lot of work spend in the futexes. > > i'm having problems with those scripts. they have a negative impact > on the linux processes. when i have the player at www.mixcloud.com > running and run those scripts the music stops and the flash graphics > get all distorted. here's some output from the trace_futexes.d script: > > otaku% sudo ./trace_futexes.d > dtrace: 808 dynamic variable drops with non-empty dirty list > dtrace: 833 failed speculations (available buffer(s) still busy) You should increase the buffers in the scripts, they are overflowing. [...] > ERROR: missing_access_check in linuxulator32:futex:futex_atomic_op This is missing code in the kernel... or a superfluous comment. > kernel`ia32_syscall+0x299 > kernel`0x805b05e5 > > dtrace: ERROR: open failed: No such file or directory > `0x287b6533 > Fatal error 'mutex is on list' at line 424 in > file /usr/github-freebsd-head/lib/libthr/thread/thr_mutex.c (errno = > 0) No idea. > this is from the check_error.d script: > > otaku% sudo ./check_error.d > ERROR: sleep_error in linuxulator32:futex:futex_sleep Well... the sx_sleep returned with a non-null value. I assume this means a timeout fired. No idea if it is good or bad. > kernel`ia32_syscall+0x299 > kernel`0x805b05e5 > > 0x287b6278 > 0x2a12800029d5fa5c > ERROR: sleep_error in linuxulator32:futex:futex_wait As above. > kernel`ia32_syscall+0x299 > kernel`0x805b05e5 > > 0x287b6278 > 0x2a12800029d5fa5c > the check_internal_locks.d scripts seems to work fine. i think we > talked about the failed-speculation-warnings beforehand and that they > aren't critical: Yes and no... you do not have enough buffers to store all the info the script want to store. As such it does not work as intended. > Number of locks per type: > emul_shared_rlock 3 > emul_shared_wlock37 > emul_lock55 > futex_mtx 31179 Depending on how long you traced: that's a lot of futex operations. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Leidinger wrote: > On Sun, 15 Apr 2012 13:03:06 + Alexander Best > wrote: > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > On Sun, 15 Apr 2012 11:51:12 + Alexander Best > > > wrote: > > > > > > > ahh ok. i've managed to get some stats via stats_timing.d. this > > > > is a snapshot during which a newly loaded tab in chromium was > > > > unresponsive for about 5 seconds. without the linux flash plugin > > > > running i never experienced such lock ups. > > > > > > > > i've attached the d-script stats. > > > > > > What about the trace_futexes script and the two check_* scripts? The > > > stats show that there is a lot of work spend in the futexes. > > > > i'm having problems with those scripts. they have a negative impact > > on the linux processes. when i have the player at www.mixcloud.com > > running and run those scripts the music stops and the flash graphics > > get all distorted. here's some output from the trace_futexes.d script: > > > > otaku% sudo ./trace_futexes.d > > dtrace: 808 dynamic variable drops with non-empty dirty list > > dtrace: 833 failed speculations (available buffer(s) still busy) > > You should increase the buffers in the scripts, they are overflowing. > > [...] > > ERROR: missing_access_check in linuxulator32:futex:futex_atomic_op > > This is missing code in the kernel... or a superfluous comment. > > > kernel`ia32_syscall+0x299 > > kernel`0x805b05e5 > > > > dtrace: ERROR: open failed: No such file or directory > > `0x287b6533 > > Fatal error 'mutex is on list' at line 424 in > > file /usr/github-freebsd-head/lib/libthr/thread/thr_mutex.c (errno = > > 0) > > No idea. > > > this is from the check_error.d script: > > > > otaku% sudo ./check_error.d > > ERROR: sleep_error in linuxulator32:futex:futex_sleep > > Well... the sx_sleep returned with a non-null value. I assume this > means a timeout fired. No idea if it is good or bad. > > > kernel`ia32_syscall+0x299 > > kernel`0x805b05e5 > > > > 0x287b6278 > > 0x2a12800029d5fa5c > > ERROR: sleep_error in linuxulator32:futex:futex_wait > > As above. > > > kernel`ia32_syscall+0x299 > > kernel`0x805b05e5 > > > > 0x287b6278 > > 0x2a12800029d5fa5c > > > the check_internal_locks.d scripts seems to work fine. i think we > > talked about the failed-speculation-warnings beforehand and that they > > aren't critical: > > Yes and no... you do not have enough buffers to store all the info the > script want to store. As such it does not work as intended. i've set #pragma D option dynvarsize=512m #pragma D option specsize=512m in check_internal_locks.d however i get a warning that the size got downgraded and still the buffers don't seem to be large enough: dtrace: dynamic variable size lowered to 256m dtrace: 220 failed speculations (available buffer(s) still busy) dtrace: 206 failed speculations (available buffer(s) still busy) dtrace: 205 failed speculations (available buffer(s) still busy) dtrace: 206 failed speculations (available buffer(s) still busy) dtrace: 182 failed speculations (available buffer(s) still busy) dtrace: 219 failed speculations (available buffer(s) still busy) dtrace: 194 failed speculations (available buffer(s) still busy) dtrace: 210 failed speculations (available buffer(s) still busy) dtrace: 218 failed speculations (available buffer(s) still busy) dtrace: 206 failed speculations (available buffer(s) still busy) dtrace: 222 failed speculations (available buffer(s) still busy) dtrace: 214 failed speculations (available buffer(s) still busy) dtrace: 213 failed speculations (available buffer(s) still busy) dtrace: 205 failed speculations (available buffer(s) still busy) dtrace: 216 failed speculations (available buffer(s) still busy) dtrace: 220 failed speculations (available buffer(s) still busy) dtrace: 210 failed speculations (available buffer(s) still busy) maybe the problem with the above errors was that my kernel got built with dtrace support, but my world didn't. i'm now rebuilding and installing world. maybe that fixes some of the issues. > > > > Number of locks per type: > > emul_shared_rlock 3 > > emul_shared_wlock37 > > emul_lock55 > > futex_mtx 31179 > > Depending on how long you traced: that's a lot of futex operations. i traced for ~ 5 seconds. i'll make sure to prepend the time command to any dtrace script next time to give you more exact numbers. cheers. alex > > Bye, > Alexander. > > -- > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Best wrote: > On Sun Apr 15 12, Alexander Leidinger wrote: > > On Sun, 15 Apr 2012 13:03:06 + Alexander Best > > wrote: > > > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > On Sun, 15 Apr 2012 11:51:12 + Alexander Best > > > > wrote: > > > > > > > > > ahh ok. i've managed to get some stats via stats_timing.d. this > > > > > is a snapshot during which a newly loaded tab in chromium was > > > > > unresponsive for about 5 seconds. without the linux flash plugin > > > > > running i never experienced such lock ups. > > > > > > > > > > i've attached the d-script stats. > > > > > > > > What about the trace_futexes script and the two check_* scripts? The > > > > stats show that there is a lot of work spend in the futexes. > > > > > > i'm having problems with those scripts. they have a negative impact > > > on the linux processes. when i have the player at www.mixcloud.com > > > running and run those scripts the music stops and the flash graphics > > > get all distorted. here's some output from the trace_futexes.d script: > > > > > > otaku% sudo ./trace_futexes.d > > > dtrace: 808 dynamic variable drops with non-empty dirty list > > > dtrace: 833 failed speculations (available buffer(s) still busy) > > > > You should increase the buffers in the scripts, they are overflowing. > > > > [...] > > > ERROR: missing_access_check in linuxulator32:futex:futex_atomic_op > > > > This is missing code in the kernel... or a superfluous comment. > > > > > kernel`ia32_syscall+0x299 > > > kernel`0x805b05e5 > > > > > > dtrace: ERROR: open failed: No such file or directory > > > `0x287b6533 > > > Fatal error 'mutex is on list' at line 424 in > > > file /usr/github-freebsd-head/lib/libthr/thread/thr_mutex.c (errno = > > > 0) > > > > No idea. > > > > > this is from the check_error.d script: > > > > > > otaku% sudo ./check_error.d > > > ERROR: sleep_error in linuxulator32:futex:futex_sleep > > > > Well... the sx_sleep returned with a non-null value. I assume this > > means a timeout fired. No idea if it is good or bad. > > > > > kernel`ia32_syscall+0x299 > > > kernel`0x805b05e5 > > > > > > 0x287b6278 > > > 0x2a12800029d5fa5c > > > ERROR: sleep_error in linuxulator32:futex:futex_wait > > > > As above. > > > > > kernel`ia32_syscall+0x299 > > > kernel`0x805b05e5 > > > > > > 0x287b6278 > > > 0x2a12800029d5fa5c > > > > > the check_internal_locks.d scripts seems to work fine. i think we > > > talked about the failed-speculation-warnings beforehand and that they > > > aren't critical: > > > > Yes and no... you do not have enough buffers to store all the info the > > script want to store. As such it does not work as intended. > > i've set > > #pragma D option dynvarsize=512m > #pragma D option specsize=512m > > in check_internal_locks.d > > however i get a warning that the size got downgraded and still the buffers > don't seem to be large enough: > > dtrace: dynamic variable size lowered to 256m > dtrace: 220 failed speculations (available buffer(s) still busy) > dtrace: 206 failed speculations (available buffer(s) still busy) > dtrace: 205 failed speculations (available buffer(s) still busy) > dtrace: 206 failed speculations (available buffer(s) still busy) > dtrace: 182 failed speculations (available buffer(s) still busy) > dtrace: 219 failed speculations (available buffer(s) still busy) > dtrace: 194 failed speculations (available buffer(s) still busy) > dtrace: 210 failed speculations (available buffer(s) still busy) > dtrace: 218 failed speculations (available buffer(s) still busy) > dtrace: 206 failed speculations (available buffer(s) still busy) > dtrace: 222 failed speculations (available buffer(s) still busy) > dtrace: 214 failed speculations (available buffer(s) still busy) > dtrace: 213 failed speculations (available buffer(s) still busy) > dtrace: 205 failed speculations (available buffer(s) still busy) > dtrace: 216 failed speculations (available buffer(s) still busy) > dtrace: 220 failed speculations (available buffer(s) still busy) > dtrace: 210 failed speculations (available buffer(s) still busy) > > maybe the problem with the above errors was that my kernel got built with > dtrace support, but my world didn't. i'm now rebuilding and installing world. > maybe that fixes some of the issues. > > > > > > > > Number of locks per type: > > > emul_shared_rlock 3 > > > emul_shared_wlock37 > > > emul_lock55 > > > futex_mtx 31179 here are the results for a single flash instance: otaku% sudo time ./check_internal_locks.d dtrace: 217 failed speculations (available buffer(s) s
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > On Sun, 15 Apr 2012 13:03:06 + Alexander Best > > > wrote: > > > > > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > > On Sun, 15 Apr 2012 11:51:12 + Alexander Best > > > > > wrote: > > > > > > > > > > > ahh ok. i've managed to get some stats via stats_timing.d. this > > > > > > is a snapshot during which a newly loaded tab in chromium was > > > > > > unresponsive for about 5 seconds. without the linux flash plugin > > > > > > running i never experienced such lock ups. > > > > > > > > > > > > i've attached the d-script stats. > > > > > > > > > > What about the trace_futexes script and the two check_* scripts? The > > > > > stats show that there is a lot of work spend in the futexes. > > > > > > > > i'm having problems with those scripts. they have a negative impact > > > > on the linux processes. when i have the player at www.mixcloud.com > > > > running and run those scripts the music stops and the flash graphics > > > > get all distorted. here's some output from the trace_futexes.d script: > > > > > > > > otaku% sudo ./trace_futexes.d > > > > dtrace: 808 dynamic variable drops with non-empty dirty list > > > > dtrace: 833 failed speculations (available buffer(s) still busy) > > > > > > You should increase the buffers in the scripts, they are overflowing. > > > > > > [...] > > > > ERROR: missing_access_check in linuxulator32:futex:futex_atomic_op > > > > > > This is missing code in the kernel... or a superfluous comment. > > > > > > > kernel`ia32_syscall+0x299 > > > > kernel`0x805b05e5 > > > > > > > > dtrace: ERROR: open failed: No such file or directory > > > > `0x287b6533 > > > > Fatal error 'mutex is on list' at line 424 in > > > > file /usr/github-freebsd-head/lib/libthr/thread/thr_mutex.c (errno = > > > > 0) > > > > > > No idea. > > > > > > > this is from the check_error.d script: > > > > > > > > otaku% sudo ./check_error.d > > > > ERROR: sleep_error in linuxulator32:futex:futex_sleep > > > > > > Well... the sx_sleep returned with a non-null value. I assume this > > > means a timeout fired. No idea if it is good or bad. > > > > > > > kernel`ia32_syscall+0x299 > > > > kernel`0x805b05e5 > > > > > > > > 0x287b6278 > > > > 0x2a12800029d5fa5c > > > > ERROR: sleep_error in linuxulator32:futex:futex_wait > > > > > > As above. > > > > > > > kernel`ia32_syscall+0x299 > > > > kernel`0x805b05e5 > > > > > > > > 0x287b6278 > > > > 0x2a12800029d5fa5c > > > > > > > the check_internal_locks.d scripts seems to work fine. i think we > > > > talked about the failed-speculation-warnings beforehand and that they > > > > aren't critical: > > > > > > Yes and no... you do not have enough buffers to store all the info the > > > script want to store. As such it does not work as intended. > > > > i've set > > > > #pragma D option dynvarsize=512m > > #pragma D option specsize=512m > > > > in check_internal_locks.d > > > > however i get a warning that the size got downgraded and still the buffers > > don't seem to be large enough: > > > > dtrace: dynamic variable size lowered to 256m > > dtrace: 220 failed speculations (available buffer(s) still busy) > > dtrace: 206 failed speculations (available buffer(s) still busy) > > dtrace: 205 failed speculations (available buffer(s) still busy) > > dtrace: 206 failed speculations (available buffer(s) still busy) > > dtrace: 182 failed speculations (available buffer(s) still busy) > > dtrace: 219 failed speculations (available buffer(s) still busy) > > dtrace: 194 failed speculations (available buffer(s) still busy) > > dtrace: 210 failed speculations (available buffer(s) still busy) > > dtrace: 218 failed speculations (available buffer(s) still busy) > > dtrace: 206 failed speculations (available buffer(s) still busy) > > dtrace: 222 failed speculations (available buffer(s) still busy) > > dtrace: 214 failed speculations (available buffer(s) still busy) > > dtrace: 213 failed speculations (available buffer(s) still busy) > > dtrace: 205 failed speculations (available buffer(s) still busy) > > dtrace: 216 failed speculations (available buffer(s) still busy) > > dtrace: 220 failed speculations (available buffer(s) still busy) > > dtrace: 210 failed speculations (available buffer(s) still busy) > > > > maybe the problem with the above errors was that my kernel got built with > > dtrace support, but my world didn't. i'm now rebuilding and installing > > world. > > maybe that fixes some of the issues. > > > > > > > > > > > > Number of locks per type: > > > > emul_shared_rlock 3 > > > > emul_shared_wlock37 > > > > emul_lock
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > > On Sun Apr 15 12, Alexander Best wrote: > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > On Sun, 15 Apr 2012 13:03:06 + Alexander Best > > > > wrote: > > > > > > > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > > > On Sun, 15 Apr 2012 11:51:12 + Alexander Best > > > > > > wrote: > > > > > > > > > > > > > ahh ok. i've managed to get some stats via stats_timing.d. this > > > > > > > is a snapshot during which a newly loaded tab in chromium was > > > > > > > unresponsive for about 5 seconds. without the linux flash plugin > > > > > > > running i never experienced such lock ups. > > > > > > > > > > > > > > i've attached the d-script stats. > > > > > > > > > > > > What about the trace_futexes script and the two check_* scripts? The > > > > > > stats show that there is a lot of work spend in the futexes. > > > > > > > > > > i'm having problems with those scripts. they have a negative impact > > > > > on the linux processes. when i have the player at www.mixcloud.com > > > > > running and run those scripts the music stops and the flash graphics > > > > > get all distorted. here's some output from the trace_futexes.d script: > > > > > > > > > > otaku% sudo ./trace_futexes.d > > > > > dtrace: 808 dynamic variable drops with non-empty dirty list > > > > > dtrace: 833 failed speculations (available buffer(s) still busy) > > > > > > > > You should increase the buffers in the scripts, they are overflowing. > > > > > > > > [...] > > > > > ERROR: missing_access_check in linuxulator32:futex:futex_atomic_op > > > > > > > > This is missing code in the kernel... or a superfluous comment. > > > > > > > > > kernel`ia32_syscall+0x299 > > > > > kernel`0x805b05e5 > > > > > > > > > > dtrace: ERROR: open failed: No such file or directory > > > > > `0x287b6533 > > > > > Fatal error 'mutex is on list' at line 424 in > > > > > file /usr/github-freebsd-head/lib/libthr/thread/thr_mutex.c (errno = > > > > > 0) > > > > > > > > No idea. > > > > > > > > > this is from the check_error.d script: > > > > > > > > > > otaku% sudo ./check_error.d > > > > > ERROR: sleep_error in linuxulator32:futex:futex_sleep > > > > > > > > Well... the sx_sleep returned with a non-null value. I assume this > > > > means a timeout fired. No idea if it is good or bad. > > > > > > > > > kernel`ia32_syscall+0x299 > > > > > kernel`0x805b05e5 > > > > > > > > > > 0x287b6278 > > > > > 0x2a12800029d5fa5c > > > > > ERROR: sleep_error in linuxulator32:futex:futex_wait > > > > > > > > As above. > > > > > > > > > kernel`ia32_syscall+0x299 > > > > > kernel`0x805b05e5 > > > > > > > > > > 0x287b6278 > > > > > 0x2a12800029d5fa5c > > > > > > > > > the check_internal_locks.d scripts seems to work fine. i think we > > > > > talked about the failed-speculation-warnings beforehand and that they > > > > > aren't critical: > > > > > > > > Yes and no... you do not have enough buffers to store all the info the > > > > script want to store. As such it does not work as intended. > > > > > > i've set > > > > > > #pragma D option dynvarsize=512m > > > #pragma D option specsize=512m > > > > > > in check_internal_locks.d > > > > > > however i get a warning that the size got downgraded and still the buffers > > > don't seem to be large enough: > > > > > > dtrace: dynamic variable size lowered to 256m > > > dtrace: 220 failed speculations (available buffer(s) still busy) > > > dtrace: 206 failed speculations (available buffer(s) still busy) > > > dtrace: 205 failed speculations (available buffer(s) still busy) > > > dtrace: 206 failed speculations (available buffer(s) still busy) > > > dtrace: 182 failed speculations (available buffer(s) still busy) > > > dtrace: 219 failed speculations (available buffer(s) still busy) > > > dtrace: 194 failed speculations (available buffer(s) still busy) > > > dtrace: 210 failed speculations (available buffer(s) still busy) > > > dtrace: 218 failed speculations (available buffer(s) still busy) > > > dtrace: 206 failed speculations (available buffer(s) still busy) > > > dtrace: 222 failed speculations (available buffer(s) still busy) > > > dtrace: 214 failed speculations (available buffer(s) still busy) > > > dtrace: 213 failed speculations (available buffer(s) still busy) > > > dtrace: 205 failed speculations (available buffer(s) still busy) > > > dtrace: 216 failed speculations (available buffer(s) still busy) > > > dtrace: 220 failed speculations (available buffer(s) still busy) > > > dtrace: 210 failed speculations (available buffer(s) still busy) > > > > > > maybe the problem with the above errors was that my kernel got built with > > > dtrace support, but my world didn't. i'm now rebuilding and installing > > > world. > > > maybe that fi
Re: [PATCH] pipe2 for Linuxulator
On Sun, 15 Apr 2012 18:16:13 + Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > here are the results for a single flash instance: > > otaku% sudo time ./check_internal_locks.d > Number of locks per type: > futex_mtx 4585 > >18,48 real 0,10 user 0,36 sys > > and here for two flash tabs: > Number of locks per type: > futex_mtx 29364 > >19,41 real 0,09 user 0,32 sys > > ...and for three flash tabs: > > otaku% sudo time ./check_internal_locks.d > Number of locks per type: > emul_shared_wlock14 > emul_lock20 > futex_mtx 45571 > >22,46 real 0,11 user 0,35 sys A lot more calls to the futex-lock than you would assume. It's not linear to the amount of flash instances. Maybe worth investigating (optimization opportunity?). > > i've tuned the script to have the maximum buffer size of 256 megabyte > via > > #pragma D option dynvarsize=256m > #pragma D option specsize=256m > > ...still the buffers seem to be too small. The scripts do a lot. The serve more as examples of what you can do, than to really serve as a debugging aid in all situations. They give a hint if there's something to investigate or not. In your case it is maybe not a bad idea to remove all emul-lock parts and only keep the futex-stuff (or a part of it...). > also...even after installing a fresh kernel and world with dtrace > enabled, the "check_error.d" and "trace_futexes.d" fail and sometimes > even render the flash instance unusable. I assume with unusable you mean not fast enough. Well... buy a faster CPU. No, just kidding. Depending on what a D script does and how many probes are enabled in the D script, it is not unexpected that the system slows down. As told above, the scripts show what is possible. For real debugging you may want to use stripped down versions. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun, 15 Apr 2012 18:29:28 + Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > running stats_timing.d revealed something strange...according to this > section: > > Number of calls per provider/application/kernel function: > linuxulator32 > npviewer.bin > proc_exit 2 > proc_exit only got callded twice. however according to this section: > > Longest running (CPU-time!) functions per provider (in ns): > linuxulator32 > proc_exit-16995 > the CPU spent a lot of time for those two calls. AFAIR proc_exit walks down a list or two. Depending on how much is going on, this may take a while. Looks like my DTrace probes and scripts offer the opportunity to do some performance related observations in an easy way. Now we just need some interested souls to actually do it and optimize some things. It would also be great if someone could have a look at http://dtrace.org/blogs/brendan/ and code up some nice GUI respectively an observation and analysis tool. Graphs as represented by Brendan give a much better way of understanding what's going on than a lot of numbers. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Leidinger wrote: > On Sun, 15 Apr 2012 18:16:13 + Alexander Best > wrote: > > > On Sun Apr 15 12, Alexander Best wrote: > > > here are the results for a single flash instance: > > > > otaku% sudo time ./check_internal_locks.d > > > Number of locks per type: > > futex_mtx 4585 > > > >18,48 real 0,10 user 0,36 sys > > > > and here for two flash tabs: > > > Number of locks per type: > > futex_mtx 29364 > > > >19,41 real 0,09 user 0,32 sys > > > > ...and for three flash tabs: > > > > otaku% sudo time ./check_internal_locks.d > > > Number of locks per type: > > emul_shared_wlock14 > > emul_lock20 > > futex_mtx 45571 > > > >22,46 real 0,11 user 0,35 sys > > A lot more calls to the futex-lock than you would assume. It's not > linear to the amount of flash instances. Maybe worth investigating > (optimization opportunity?). > > > > > i've tuned the script to have the maximum buffer size of 256 megabyte > > via > > > > #pragma D option dynvarsize=256m > > #pragma D option specsize=256m > > > > ...still the buffers seem to be too small. > > The scripts do a lot. The serve more as examples of what you can do, > than to really serve as a debugging aid in all situations. They give a > hint if there's something to investigate or not. In your case it is > maybe not a bad idea to remove all emul-lock parts and only keep the > futex-stuff (or a part of it...). thanks for the hint. i'll try to comment out any non-futex related stuff. > > > also...even after installing a fresh kernel and world with dtrace > > enabled, the "check_error.d" and "trace_futexes.d" fail and sometimes > > even render the flash instance unusable. > > I assume with unusable you mean not fast enough. Well... buy a faster > CPU. No, just kidding. Depending on what a D script does and how many > probes are enabled in the D script, it is not unexpected that the > system slows down. As told above, the scripts show what is possible. > For real debugging you may want to use stripped down versions. no actually. what i meant by "unusable" is that the d-scripts themself crash the flash instances. > > Bye, > Alexander. > > -- > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun, 15 Apr 2012 18:46:43 + Alexander Best wrote: > On Sun Apr 15 12, Alexander Best wrote: > eventually after trying a lot of time i managed to gather some stats > from the "trace_futexes.d" script: > Wallclock-timing statistics per provider/application/kernel function > (in ns): linuxulator32 > |@4 -268435456 > | 0 -134217728 > |@@@ 6 -67108864 > |@1 -33554432 > |@1 -16777216 I worry a little bit about the negative values here (and at other places). Or do I just not remember that DTrace uses the dash to denote "up to"? I don't have the time now to investigate. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun, 15 Apr 2012 19:04:08 + Alexander Best wrote: > On Sun Apr 15 12, Alexander Leidinger wrote: > > On Sun, 15 Apr 2012 18:16:13 + Alexander Best > > wrote: > > > also...even after installing a fresh kernel and world with dtrace > > > enabled, the "check_error.d" and "trace_futexes.d" fail and > > > sometimes even render the flash instance unusable. > > > > I assume with unusable you mean not fast enough. Well... buy a > > faster CPU. No, just kidding. Depending on what a D script does and > > how many probes are enabled in the D script, it is not unexpected > > that the system slows down. As told above, the scripts show what is > > possible. For real debugging you may want to use stripped down > > versions. > > no actually. what i meant by "unusable" is that the d-scripts > themself crash the flash instances. Uhm... this is unexpected. DTrace disables destructive actions by default, and I do not activate them. Maybe some timing-sensitive code in the flash-player which does not handle the case that some parts can take longer than expected? I assume there is not bug in DTrace itself. There could be a bug in my patch, but I would assume it is not a heisen-bug as described here (the probes are handled by DTrace-macros, just the variables which are provided to D scripts are different from other probes). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Leidinger wrote: > On Sun, 15 Apr 2012 19:04:08 + Alexander Best > wrote: > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > On Sun, 15 Apr 2012 18:16:13 + Alexander Best > > > wrote: > > > > > also...even after installing a fresh kernel and world with dtrace > > > > enabled, the "check_error.d" and "trace_futexes.d" fail and > > > > sometimes even render the flash instance unusable. > > > > > > I assume with unusable you mean not fast enough. Well... buy a > > > faster CPU. No, just kidding. Depending on what a D script does and > > > how many probes are enabled in the D script, it is not unexpected > > > that the system slows down. As told above, the scripts show what is > > > possible. For real debugging you may want to use stripped down > > > versions. > > > > no actually. what i meant by "unusable" is that the d-scripts > > themself crash the flash instances. > > Uhm... this is unexpected. DTrace disables destructive actions by > default, and I do not activate them. Maybe some timing-sensitive code > in the flash-player which does not handle the case that some parts can > take longer than expected? I assume there is not bug in DTrace itself. > There could be a bug in my patch, but I would assume it is not a > heisen-bug as described here (the probes are handled by > DTrace-macros, just the variables which are provided to D scripts > are different from other probes). this sounds reasonable. after exiting the dtrace script the crashed flash instance partially returns to normal behaviour. so indeed it seems that dtrace is having only an impact on flash's timing-code. none of the linux processes actually crashes (that is is being terminated) in this scenario. ps alx shows that all processes still exist. i'll play a bit more with the dtrace scripts and see if i can remove more stuff that isn't important for futex related matters. good night. alex > > Bye, > Alexander. > > -- > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [PATCH] pipe2 for Linuxulator
On Sun Apr 15 12, Alexander Best wrote: > On Sun Apr 15 12, Alexander Leidinger wrote: > > On Sun, 15 Apr 2012 19:04:08 + Alexander Best > > wrote: > > > > > On Sun Apr 15 12, Alexander Leidinger wrote: > > > > On Sun, 15 Apr 2012 18:16:13 + Alexander Best > > > > wrote: > > > > > > > also...even after installing a fresh kernel and world with dtrace > > > > > enabled, the "check_error.d" and "trace_futexes.d" fail and > > > > > sometimes even render the flash instance unusable. > > > > > > > > I assume with unusable you mean not fast enough. Well... buy a > > > > faster CPU. No, just kidding. Depending on what a D script does and > > > > how many probes are enabled in the D script, it is not unexpected > > > > that the system slows down. As told above, the scripts show what is > > > > possible. For real debugging you may want to use stripped down > > > > versions. > > > > > > no actually. what i meant by "unusable" is that the d-scripts > > > themself crash the flash instances. > > > > Uhm... this is unexpected. DTrace disables destructive actions by > > default, and I do not activate them. Maybe some timing-sensitive code > > in the flash-player which does not handle the case that some parts can > > take longer than expected? I assume there is not bug in DTrace itself. > > There could be a bug in my patch, but I would assume it is not a > > heisen-bug as described here (the probes are handled by > > DTrace-macros, just the variables which are provided to D scripts > > are different from other probes). > > this sounds reasonable. after exiting the dtrace script the crashed flash > instance partially returns to normal behaviour. so indeed it seems that > dtrace is having only an impact on flash's timing-code. > > none of the linux processes actually crashes (that is is being terminated) in > this scenario. ps alx shows that all processes still exist. > > i'll play a bit more with the dtrace scripts and see if i can remove more > stuff that isn't important for futex related matters. one more thing: i'm seeing a lot of defunct processes in connection with flash: 1001 1023 9880 4 0 283916 56620 kqread I -2:36,17 chrome: --type=plugin --plugin-path=/usr/home/arundel/.mozilla/plugins/npwrapper.libflashplayer.so --lang=en-GB --channel=988.0x65c6b90.321991751 (chrome) 1001 1047 10230 20 0 0 0 -Z -0:00,01 1001 1048 10230 20 0 0 0 -Z -0:00,01 1001 1049 10230 20 0 0 0 -Z -0:00,01 1001 1050 10230 20 0 0 0 -Z -0:00,01 1001 1052 10230 20 0 0 0 -Z -0:00,01 1001 1065 10230 20 0 0 0 -Z -0:00,01 1001 1067 10230 20 0 0 0 -Z -0:05,89 1001 1069 10230 20 0 0 0 -Z -0:00,01 1001 1074 9880 40 0 292244 86844 uwaitS -0:26,94 chrome: --type=gpu-process --channel=988.0x67e2960.1399124120 (chrome) 1001 1544 9900 40 0 922080 129268 usem S -2:05,13 chrome: --type=zygote (chrome) 1001 1558 10233 40 0 577080 91848 futexI -0:00,28 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin .mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/1023-4/1681692777 1001 1559 10231 40 0 577080 91848 futexI -0:00,00 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin .mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/1023-4/1681692777 1001 1605 10230 20 0 0 0 -Z -0:00,01 1001 1606 10230 20 0 0 0 -Z -0:00,01 1001 1607 10230 20 0 0 0 -Z -0:00,01 1001 1609 10230 20 0 0 0 -Z -0:00,01 1001 1610 10230 20 0 0 0 -Z -0:00,01 1001 1611 10230 20 0 0 0 -Z -0:00,01 1001 1614 10230 20 0 0 0 -Z -0:00,01 1001 1615 10230 20 0 0 0 -Z -0:00,49 1001 1616 10230 20 0 0 0 -Z -0:07,52 1001 1655 10230 20 0 0 0 -Z -0:00,00 1001 1656 10237 40 0 577080 91848 futexI -0:00,28 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin .mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/1023-4/1681692777 1001 1657 10235 40 0 577080 91848 futexI -0:00,32 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin .mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/1023-4/1681692777 1001 1713 1023 21 41 0 297812 41476 futexI -0:00,01 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin .mozilla/plugins/lib
