On 08/02/2013 20:04, Matt Burke wrote:
I've been spending some time trying to get the fasttrap provider to work
on FreeBSD without panicing. I believe I have succeeded, at least to the
point where it's no longer panicing.
There were two panic causes. The first was
http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
the early return and reverted to the opensolaris way.
A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
was run while something in userland had locks. Using sx_try_xlock calls
has stopped the panics and shouldn't affect operation AFAICT.
This is against r246454.
Although this has fixed the panics for me, I'm finding a lot of stuff just
isn't actually working, with dtrace and the traced process just chewing
CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
have no idea what the target is doing... CPU time is split 2:1
dtrace:target
Also noteworthy is the LOR on the first time you try to use the fasttrap
provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
The lock order there seems right, so I'm guessing "something else" must
have done it wrong first? How can I find out what the "something else"
is?
Hi Matt,
It might be worth posting the question to the dtrace list if your
question is unanswered.
http://dtrace.org/blogs/mailing-list/
Regards,
Sevan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
