Re: panic on acpi_cpu_c1()

From: Hans Ottevanger <hansot_at_iae.nl>
Date: Sun, 28 Jun 2009 19:21:05 +0200
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.

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"
> 
Received on Sun Jun 28 2009 - 15:31:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC