Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LOCK_PROFILING

0 views
Skip to first unread message

Pramod Srinivasan

unread,
Aug 19, 2009, 2:30:25 AM8/19/09
to
Hi Folks,

I have a difficult problem I am stuck with, we had ported LOCK_PROFILING to
FreeBSD 6.1 and is working fine on mips, but fails miserably on i386.

Just enabling lock profiling by the sysctl causes the cpu to reset.

root@bcdcpu3% sysctl debug.lock.prof.enable=1
debug.lock.pr? << cpu resets here

Has any one seen similar issues? Any pointers on where to start debugging
this issue?

The suspicion is that the spin-lock is perhaps contributing to the problem,
but have not been able to get to the bottom.

Thanks,
Pramod

_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "freebsd-smp...@freebsd.org"

John Baldwin

unread,
Aug 19, 2009, 7:57:01 AM8/19/09
to
On Wednesday 19 August 2009 2:30:25 am Pramod Srinivasan wrote:
> Hi Folks,
>
> I have a difficult problem I am stuck with, we had ported LOCK_PROFILING to
> FreeBSD 6.1 and is working fine on mips, but fails miserably on i386.
>
> Just enabling lock profiling by the sysctl causes the cpu to reset.
>
> root@bcdcpu3% sysctl debug.lock.prof.enable=1
> debug.lock.pr? << cpu resets here
>
> Has any one seen similar issues? Any pointers on where to start debugging
> this issue?
>
> The suspicion is that the spin-lock is perhaps contributing to the problem,
> but have not been able to get to the bottom.

It sounds like a tripe fault. I suspect you are recursing on your stack
somehow leading to a double fault that faults again trying to get a lock to
output to the console perhaps (that would explain the lack of double fault
messages if that were the case). Perhaps a lock used in the profiling is
incorrectly being profiled?

--
John Baldwin

Pramod Srinivasan

unread,
Aug 21, 2009, 5:10:02 AM8/21/09
to
Hi John,

On 8/19/09 4:57 AM, "John Baldwin" <j...@freebsd.org> wrote:
>
> It sounds like a tripe fault. I suspect you are recursing on your stack
> somehow leading to a double fault that faults again trying to get a lock to
> output to the console perhaps (that would explain the lack of double fault
> messages if that were the case). Perhaps a lock used in the profiling is
> incorrectly being profiled?

Yes, this is right!!

The clock_lock was not initialized with MTX_NOPROFILE, and we ended up
profiling the clock_lock recursively until we overflowed the stack. Thanks
for pointing out.

Thanks,
Pramod

0 new messages