panic on acpi_cpu_c1()

Hans Ottevanger hansot at iae.nl
Sun Jun 28 20:37:54 UTC 2009


Robert Noland wrote:
> On Sun, 2009-06-28 at 22:36 +0400, Anonymous wrote:
>> Hans Ottevanger <hansot at iae.nl> 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.
> 
> drm is a consumer of msi if the hardware is capable.  If you disable msi
> you won't take the path that 194985 fixes, or any path that involves
> msi...  The panic message seemed rather unhelpful to me and I can't
> think of a reason that it would work as a module and not if it is
> compiled in.  Did you clean your kernel and rebuild?
> 

Hi,

I updated my tree to the appropriate revision, completely deleted 
/usr/obj and rebuilt using "make buildkernel KERNCONF=TEST && make 
installkernel KERNCONF=TEST". I suppose that should do the trick.

Kind regards

Hans

> robert.
> 
>>> 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 at 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);
>>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> _______________________________________________
>> 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"



More information about the freebsd-current mailing list