DragonFly submit List (threaded) for 2006-11
DragonFly BSD
DragonFly submit List (threaded) for 2006-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

ACPI-CA update patch for review


From: YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>
Date: Wed, 29 Nov 2006 22:21:03 +0900

Hello.
Here's a patch against HEAD(probably applies to Preview) to update ACPI-CA
code in our tree to 20060912 with help from Jeffrey Hsu:
  http://leaf.dragonflybsd.org/~y0netan1/acpi-20060912-14.diff

How to compile:
  1. fetch above patch, and the new ACPI-CA code from Intel site:
  $ cd
  $ fetch http://leaf.dragonflybsd.org/~y0netan1/acpi-20060912-14.diff
  $ fetch http://developer.intel.com/technology/iapc/acpi/downloads/acpica-unix-20060912.tar.gz

  2. extract the ACPI-CA code under /sys/contrib/dev
  $ tar -C /sys/contrib/dev -zxf ~/acpica-unix-20060912.tar.gz

  3. apply the patch to the source tree
  $ patch -d /usr/src -p0 < ~/acpi-20060912-14.diff

  4. build and install the acpi module, then reboot
  $ cd /sys/dev/acpica5
  $ export MAKEOBJDIRPREFIX=$HOME/obj
  $ make obj && make depend && make
  $ su
  # make install && reboot

Some known issues:
- a warning upon reboot which looks like this:

  AcpiOsUnmapMemory: Warning, broken ACPI, bad unmap: 0xc5e1ee00/00000040

  IIRC, I've never seen this before updating my patch from 20060707 to
  20060912, so I may have done something stupid while dealing with the
  changes with regard to Table Manager.  I'm investigating this.

- hand-rolled locking code in AcpiOs{Acquire,Release}Lock() functions:
  ACPI-CA code has been rewritten in 20060623 to make these functions
  to be used as spinlock functions, and called from many places where
  they weren't before.  Since our implementation of these locking functions
  used lockmgr lock, which cannot be called from cpu_idle(), this led to
  a panic(mainly when my laptop wakes up from sleep state).  After struggling
  with other locking primitives, I ended up with critical section and
  special-cased the idlethread.  I believed this shouldn't make the situation
  worse, as ACPI functions called from cpu_idle_hook code in acpi_cpu did
  not using locking before.  But I'm open to a better implementation,
  especially how to deal with locking when called from idlethread.

- new ACPI-CA code may be released soon, as 20060912 is more than 2-months
  old now

  absolutely :)


Regards.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]