Re: 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@xxxxxx>]

Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
> YONETANI Tomokazu <qhwt+dfly@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