From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 19:29:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22B11065672; Sun, 28 Jun 2009 19:29:49 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB408FC22; Sun, 28 Jun 2009 19:29:49 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id n5SJThlj084354; Sun, 28 Jun 2009 21:29:48 +0200 (CEST) (envelope-from hansot@iae.nl) Message-ID: <4A47C4A6.3050001@iae.nl> Date: Sun, 28 Jun 2009 21:29:42 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Anonymous References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> In-Reply-To: <86bpo8b3y8.fsf@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:29:50 -0000 Anonymous wrote: > Hans Ottevanger writes: > >> Norikatsu Shigemura wrote: >>> Hi. >>> >> Hi, >> >> I have almost the same issue, just the addresses are different and in >> my case the trap occurs on cpu2. >> >> My system is based on an Intel PB965LT main board with a Q6600 quad >> core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where >> kernel configuration is almost identical to GENERIC, with devices >> removed that I do not have and the following lines added >> >> device drm >> device radeondrm >> device sound >> device snd_hda >> >> If I remove the drm and radeondrm devices from the config file and >> recompile the kernel, the panic does not occur and the corresponding >> modules can be loaded without a problem. > > Can you try to boot with DRM and hw.drm.msi=0? In my case it does not > panic then. > Hi, I have just tried this with r195137 and the drm devices described above in my kernel configuration file. If I specify "set hw.drm.msi=0" from the loader prompt -no- panic occurs, otherwise it does. So it appears that this workaround works. Kind regards, Hans >> Some "binary searching" of Subversion releases shows that the problem >> first occurs with r194985. If I update to r195137 and revert the >> relevant files from the revision r194985 to r194984, no panic occurs. >> >> Of course it could very well be that r194985 itself is not the issue, >> but triggers a problem somewhere else in the kernel. >> >> Kind regards, >> >> Hans >> >>> I got a panic after AP CPU launched on boot. So I couldn't get >>> crash dump and information. >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49: Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO amd64 >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> SMP: AP CPU #3 Launched! >>> SMP: AP CPU #1 Launched! >>> SMP: AP CPU #2 Launched! >>> >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff804bce56 >>> stack pointer = 0x20:0xffffff8000039b60 >>> frame pointer = 0x20:0xffffff8000039b70 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, IOPL = 0 >>> current process = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at acpi_cpu_c1+0x6: leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >>> --- trap 0, rip = 0, rsp = 0xffffff8000039d40, rbp = 0 --- >>> db> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> >>> I can boot with kern.smp.diabled=1, so I get address lines. >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> (kgdb) list *acpi_cpu_c1+0x6 >>> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi_machdep.c:100). >>> 95 >>> 96 void >>> 97 acpi_cpu_c1() >>> 98 { >>> 99 __asm __volatile("sti; hlt"); >>> 100 } >>> (kgdb) list *acpi_cpu_idle+0x20c >>> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_cpu.c:966). >>> 961 ACPI_ENABLE_IRQS(); >>> 962 >>> 963 /* Find the actual time asleep in microseconds. */ >>> 964 end_time = acpi_TimerDelta(end_time, start_time); >>> 965 sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + PM_USEC(end_time)) / 4; >>> 966 } >>> (kgdb) list *sched_idletd+0x123 >>> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c:2562). >>> 2557 cpu_spinwait(); >>> 2558 } >>> 2559 } >>> 2560 switchcnt = tdq->tdq_switchcnt + tdq->tdq_oldswitchcnt; >>> 2561 if (tdq->tdq_load == 0) >>> 2562 cpu_idle(switchcnt > 1); >>> 2563 if (tdq->tdq_load) { >>> 2564 thread_lock(td); >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >