Date: Sun, 15 Feb 2009 18:11:14 +0300 From: Chagin Dmitry <dchagin@freebsd.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: current@freebsd.org Subject: Re: Dtrace panic'ed Message-ID: <20090215151114.GA2422@dchagin.static.corbina.ru> In-Reply-To: <4995A792.5050003@cs.duke.edu> References: <4995A792.5050003@cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> {
> @a[stack(20)]=count();
> }
>
> END
> {
> trunc(@a, 20);
> printa(@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090215151114.GA2422>