OpenBSD Journal

acpi support

Contributed by mk/reverse on from the fancy-hardware-technology dept.

Thorsten Lockert recently committed ACPI support:

Log message:
Start on a basic ACPI framework -- does not do much more than read out the
ACPI tables into kernel memory and attach ACPI and HPET timers currently.

This is very interesting, but the code is not yet feature-complete and requires lots of testing, so it's currently not hooked into the build.

Read the complete commit message.

(Comments are closed)


Comments
  1. By Anonymous Coward (194.85.97.83) on

    AFAIK Theo hates ACPI.

    Comments
    1. By Anonymous Coward (213.23.134.92) on

      Why?

      Comments
      1. By uriel (82.182.149.44) on

        Because any sane person would hate ACPI, one of the wort ideas in a long time, and that not counting the broken implementations someone else already posted about.

        Comments
        1. By Anonymous Coward (213.118.35.56) on

          No. ACPI is one of the best ideas in a long time. Don't confuse poor implementations with poor ideas.

          Comments
          1. By Anonymous Coward (65.167.23.134) on

            You sound like one of the minor characters from Deus Ex.

        2. By Anonymous Coward (204.214.120.254) on

          perhaps some reasoning as to why it is one of the worst ideas in a long time?

          Comments
          1. By tedu (64.173.147.27) on

            http://www.cpqlinux.com/acpi-howto.html#my_dsdt_fixes
            "I then changed my 0xa7 to 0xa8:"

            http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html
            "An easy way to override this is to set hw.acpi.osname="Windows 2001" in /boot/loader.conf"

            http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.1
            "Some ACPI-related changes were recently made to i8042 discovery for ia64.
            Unfortunately this broke a significant number of Dell laptops due to their having incorrect BIOS tables."

            Comments
    2. By Anonymous Coward (87.78.0.106) on

      acpi is funny stuff.
      microsoft made some "mistakes" in their implementation.
      the motherboard makers implemented those mistakes to have their acpi-features supported.
      so if you want to develope acpi support you always have to work around those "faulty" mainboards. (sry it's late)

      Comments
      1. By Anonymous Coward (207.171.180.101) on

        So it's Microsoft's fault. Again!

        Comments
        1. By Bert (68.100.43.184) blambert at thepresidency dot org on

          Isn't it always? :p

          Comments
          1. By Fábio Olivé Leite (156.153.255.236) fabio.olive@Google Mail on

            It's been a few years now that I've come to perceive such "mistakes" coming from Microsoft not as their fault, but as part of a carefully architected plan to keep the rest of the world spinning around them as much as they can.

            They used to protect theit monopoly position by the well known "Embrace and Extend" tactics of producing seemingly better protocols/formats only slightly incompatible with the standards. Very soon everybody else who wants to play has to bow and implement the slightly incompatible version and it becomes a de facto standard. The "Embrace and Extend" tactic got too old-fashioned and easy to spot, so now it's been recycled to something like "Embrace and Distort".

            In this new "Embrace and Distort" tactic they get standards wrong on purpose so that they still get everyone to jump when they say jump. It doesn't have to be Microsoft ACPI anymore, it's just ACPI. But whoever sets out to implement such distorted standards sooner or later finds out they are heavily influenced by some "[mis-]take" (noun, 5th meaning) from Microsoft.

            When people call them on it later on they can always say "Oh, but the standard is so dificult to get right!" (they distorted it) or "Hey, it's a bug!" (feature).

            OK, the above sounds conspirational, I have no evidence, no facts, blah blah. Whatever. It's just my opinion.

      2. By Observer (203.26.16.67) on

        When I first read about microsoft and hardware manufacturers working on the acpi spec i suspected they were doing this to introduce further advantages to windows over *nix

  2. By Oliver E. (62.65.148.234) on

    Notepbooks such as the (noisy, poor quality) Sony R600 series I own will not see interrupts assigned to their cardbus bridge without ACPI interrupt routing. More and more systems rely exclusively on ACPI for resource handling. Good ACPI support is the #1 feature I would like to see implemented; Without it, OpenBSD is not an option on this system.

  3. By Anonymous Coward (213.118.35.56) on

    What about the FreeBSD ACPI efforts? I seem to remember that a lot of work has gone into that recently, particularly for laptops. Is any of this code useable on OpenBSD at all?

    Comments
    1. By Anonymous Coward (193.63.217.208) on

      IIRC the FreeBSD code is based on stuff they got from Intel with a distinctly non-free license. Whatever Theo's feelings on ACPI, his view on non-free licenses is bang on :)

      Comments
      1. By Anonymous Coward (24.130.94.216) on

        I don't know about that. I thought Intel has the ACPI code under a BSD-like license. Let me see what I can find about this.

        Here's some links. Some are kind of old.

        http://news.zdnet.com/2100-3513_22-984769.html
        http://www.uwsg.iu.edu/hypermail/linux/kernel/0302.0/1091.html
        http://bsdnews.com/view_story.php3?story_id=3540

        Like I said, those links are old but one would gather that the ACPI-CA is under a BSD license. But why do I just not feel 100% sure on that? The real proof would be finding something on Itel's site regarding that, but I didn't find anything in my quick search.

        Comments
      2. By Anonymous Coward (63.174.231.179) on

        Since when is the acpi support in freebsd non-free? It's distributed under a bsd license.

        Comments
        1. By Janne Johansson (82.182.176.20) on

          If the FreeBSD code comes from the intel-license linked to above, and has this text in it "Licensee shall not export, either directly or indirectly, any of this software or system incorporating such software without first obtaining any required license or other approval from the U. S. Department of Commerce or any other agency or department of the United States Government." then it is far from free.

    2. By tedu (64.173.147.27) on

      that's where acpidump came from. but even with all the work on it, it doesn't work reliably for all people. just check the cvs logs or read their mailing lists. again, this is a mix of acpi the concept being broken and acpi the implementation being buggy, but not necessarily the freebsd developers' fault.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]