On 2011-06-30 1:59 PM, Andriy Gapon wrote:
on 30/06/2011 19:32 Ed VanderPloeg said the following:
I updated to 8-stable but am still getting ACPI error messages to console every
Just for my curiosity - has anything changed with respect to est driver
I'm not sure what you mean by "attachment". With 8-stable now installed:
stanbud# kldstat -v | grep est
Is there anything you would like me to check?
What happens when sysctl hw.acpi.thermal.polling_rate=0? Does this disable
polling? I noticed that when I set it to zero, the error messages seem to stop,
but then setting it to a non-zero value never brings the messages back again.
I've just the code in acpi_thermal driver and it doesn't have any validation for
polling_rate and thus no special treatment for the value of zero. So, it passes
timeout of zero to msleep() function, which does have a special meaning for zero
- it means sleep forever until wakeup event. Essentially when you did sysctl
hw.acpi.thermal.polling_rate=0, you made the thermal zone handling thread to
sleep "forever". This can be considered a bug in FreeBSD ACPI TZ driver. The
only thing that seems to be able to wake up the thread after that is a change of
power profile. So switching from AC to batter or vice versa could wake up the
thread and make it use a new value of polling_rate.
On 2011-06-29 12:45 PM, Andriy Gapon wrote:
on 29/06/2011 21:01 Ed VanderPloeg said the following:
On 2011-06-29 2:38 AM, Andriy Gapon wrote:
on 29/06/2011 01:07 Ed VanderPloeg said the following:
I'm using an Aaeon AEC-6831 embedded system based on an Intel Atom N270, which
uses their GENE-9455 motherboard. After updating the BIOS to enable ACPI, I'm
now getting the following (verbose) console message during boot and every 10
ACPI Error: [RTMP] Namespace lookup failure, AE_NOT_FOUND
ACPI Error: Method parse/execution failed [\_TZ_.THRM._TMP] (Node 0xc56b0760),
acpi_tz0: error fetching current temperature -- AE_NOT_FOUND
The problem is that RTMP is defined as an external object:
External (RTMP, IntObj)
so it's supposed to come from an additional table, but apparently either no
additional table defines it or a necessary additional table is not loaded.
This could be either a BIOS problem or... something else :)
Aaeon tech support has now stated that the errors are from a faulty BIOS, and
that AWARD will eventually release an update to fix this.
The unit seems to run very warm which makes me wonder if this problem is
preventing lower power states, if such things are related.
I've collected the outputs from a verbose dmesg, from sysctl hw.acpi, and from
acpidump. They are zipped up over here:
Try either recent stable/8 or head (aka CURRENT) and see if it helps. They
contain a change that may be a work-around for a BIOS (ACPI tables) like yours.
I'll give stable/8 a try.
Does this error indicate something potentially harmful, or if it is benign? I
can silence the messages easy enough until a BIOS update comes out.
Actually I was speaking about potentially making est driver attach on your
system. I also suspected that RTMP might have gotten loaded from the same
dynamic table that is related to est attachment issue, but apparently that was
not going to happen.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"