cvs commit: src/sys/boot/pc32/libi386 biosacpi.c src/sys/conf acpi.mk files src/sys/dev/acpica5 Makefile Makefile.inc acdragonfly.h acpi.c acpi_acad.c acpi_button.c acpi_cmbat.c acpi_cpu.c acpi_ec.c acpi_lid.c acpi_resource.c acpi_thermal.c ...
Johannes Hofmann
Johannes.Hofmann at gmx.de
Thu Jan 18 10:57:42 PST 2007
Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
> YONETANI Tomokazu <qhwt+dfly at les.ath.cx> wrote:
>> Hmm, db_print_backtrace() should print the backtrace, but it may not be
>> very useful if you can't use the keyboard and the trace is too deep.
>>
>>> So I suspect that there is something wrong with the debugging code.
>>> Does function tracing work for you?
>>
>> Yes, with or without ACPI_DEBUG_{LOCKS,MEMMAP}
>> (but the message buffer is too short to hold the whole trace).
>> http://les.ath.cx/DragonFly/dmesg.boot
>>
>> Cheers.
>
> Just an update. It seems that after a while it does not return from
>
> Status = WalkState->DescendingCallback (WalkState, Op);
>
> in interpreter/parser/psloop.c:AcpiPsBuildNamedOp.
>
> BTW, is there a way to enable more verbose logging, so that all
> ACPI_FUNCTION_TRACE_PTR() calls would give some output. That way
> I could avoid adding all those kprintfs.
>
> Johannes
Uff, now I've got it.
It hangs in OsdCache.c:AcpiOsAcquireObject
Object = objcache_get(Cache->cache, M_WAITOK);
Any ideas?
Johannes
More information about the Commits
mailing list