Re: Dtrace panic'ed

On Fri, Feb 13, 2009 at 12:02:10PM -0500, 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.
> 
> 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
> 
> 

hi, I have the same problem and found the hack "solution":

dchagin# sysctl machdep.idle=hlt
machdep.idle: acpi -> hlt

thnx!
-- 
Have fun!
chd