panic on acpi_cpu_c1()

Robert Noland rnoland at FreeBSD.org
Sun Jun 28 23:04:35 UTC 2009


On Sun, 2009-06-28 at 23:27 +0300, Kostik Belousov wrote:
> On Sun, Jun 28, 2009 at 03:18:26PM -0500, 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?
> Trap 30 is usually indicates that interrupts were enabled before the
> handler was established.

Hrm, That might make some sense.  drm allocates the resources for
interrupts when the driver loads.  It doesn't setup the handler until
something opens the drm device.  Still unclear how it is different for
module vs. in-kernel.

robert.

> rsvd is set as a filler for unused IDT entries.
> > 
> > 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"
> > -- 
> > Robert Noland <rnoland at FreeBSD.org>
> > FreeBSD
> 
> 
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090628/cce9aa60/attachment.pgp


More information about the freebsd-current mailing list