Re: Dtrace panic'ed

On Fri, 13 Feb 2009, Andrew Gallatin wrote:

> I was trying to run a simple dtrace profiling script, and panic'ed the 
> machine using today's -current on an 8-way opteron.

Oh, you actually got a panic using the profile provider?  For me the box 
appears to go into la-la land.  I've also seen a few double faults using fbt a 
bit too gratuitously.  Unfortunately, I haven't found time to debug it, but I 
wondered if perhaps DTrace is not recognizing its own functions (i.e., ones it 
shouldn't try to trace) properly and/or failing to disable interrupts or enter 
a critical section at important moments.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> I tried to run:
> #!/usr/sbin/dtrace -s
>
> profile:::profile-997
> {
>        _at_a[stack(20)]=count();
> }
>
> END
> {
>        trunc(_at_a, 20);
>        printa(_at_a);
> }
>
> Everything was fine until I hit ^C.  This appeared
> on the tty (which I expected):
>
> dtrace: script '/nfs/home/gallatin/dtrace/profile_stack.d' matched 2 probes
> ^C
> CPU     ID                    FUNCTION:NAME
>  1      2                             :END
>
>              kernel`vm_page_splay+0x5b
>              kernel`trap+0x482
>              kernel`0xffffffff807eb8f3
>                1
>
>              kernel`vm_fault+0x1e2
>                1
>
>              kernel`pagezero+0x17
>                1
>
>              kernel`cpu_idle+0x1
>                1
>
>              kernel`pmap_enter+0x6f
>              kernel`0xffffffff807eb8f3
>                1
>
>                4
>
>              kernel`pagezero+0x11
>                4
>
>              kernel`acpi_cpu_c1+0x6
>              kernel`0xffffffff807ebd4e
>            14063
>
> And then the machine fell over with this on console:
>
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 7; apic id = 07
> fault virtual address   = 0x20
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x8:0xffffffff80e33187
> stack pointer           = 0x10:0xfffffffe4004aa70
> frame pointer           = 0x10:0xfffffffe4004aa80
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 11 (idle: cpu7)
> trap number             = 12
> panic: page fault
> cpuid = 7
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> panic() at panic+0x182
> trap_fatal() at trap_fatal+0x2ad
> trap_pfault() at trap_pfault+0x294
> trap() at trap+0x38b
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0xffffffff80e33187, rsp = 0xfffffffe4004aa70, rbp = 
> 0xfffffffe4004aa80 ---
> cyclic_disable_xcall() at cyclic_disable_xcall+0x7
> smp_rendezvous_action() at smp_rendezvous_action+0xb3
> Xrendezvous() at Xrendezvous+0x64
> --- interrupt, rip = 0xffffffff807e3cf6, rsp = 0xfffffffe4004ab70, rbp = 
> 0xfffffffe4004ab80 ---
> acpi_cpu_c1() at acpi_cpu_c1+0x6
> acpi_cpu_idle() at acpi_cpu_idle+0x19c
> sched_idletd() at sched_idletd+0x234
> fork_exit() at fork_exit+0x118
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xfffffffe4004ad40, rbp = 0 ---
> Uptime: 5m14s
> Physical memory: 8177 MB
> Dumping 506 MB: 491 475 459 443 427 411 395 379 363 347 331 315 299 283 267 
> 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11
>
>
> Cheers,
>
> Drew
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>