OpenBSD Journal

ACPI Attohackathon: Developer Interview

Contributed by dwc on from the Amalgamated-Coder-Punishement-Interface dept.

ACPI (Advanced Configuration and Power Interface) is the defacto standard to replace APM. As such, it's becoming increasingly important for full support on newer machines, as legacy support for APM is waning and ACPI-only machines become more common. Recently there was a flurry of commits related to ACPI, which got the attention of some people running -current with ACPI enabled kernels. In this interview we get a peek at what's been happening with ACPI and where it's headed.

The interviewed developers are:
Bob Beck (beck@)
Can Erkin Acar (canacar@)
Tobias Weingartner (toby@)

Other "attohackathon" developers include:
Gordon Willem Klok (gwk@)
Chris Kuethe (ckuethe@)
Mark Kettenis (kettenis@)
Jordan Hargrave (jordan@)

Read on for the interview…

dwc> It looks like a lot of exciting things went on with ACPI, and it's nice to see the commits. Having ACPI actually do something is pretty cool. Was this an organized hackathon?

beck> Kind of. Basically it was an "attohackathon" in Edmonton Alberta.

A few of us (Gordon, Toby, GWK, and Ckuethe) live here, and have varying degrees of success occasionally getting together to work through problems, even if it's just looking through code together.

A bunch of us have been annoyed over the crappy level of acpi support and Toby and GWK in particular were keen on doing something about it, but we needed some of the other people who work in the area.

Basically we invited Jordan and Can to come visit us for a weekend. I did some organizing, an paid for a hotel room, and wrote letters for visas. We mooched a hacking room that we were graciously allowed to use by the Department of Computing Science at the University of Alberta, and we all brought various "problem children" machines — everything from the Vaio UX, IBM X60's, the "Ferrari" Acer laptop (shudder) and the infamous "crash-o-tron" Intel box I bought ckuethe at one point for work.

canacar> Bob summarized this quite nicely. I was glad to be a part of this event, and it made me feel good to be finally addressing the issues and make ACPI support go forward.

toby> Organized yes. It was a bunch of us sitting around in Bob's basement telling each other that in order for ACPI to go forward we'd like to get Jordan and Can to Edmonton to work on it together. Bob made the arrangements happen. :)

dwc> When ACPI is enabled, what differences will users notice?

beck> Some things that used to work won't. Some laptops will be able to see sensors and halt -p, some will have thermal management for the first time… Some will have horrible things happen and crash and burn. YMMV — this is why acpi is not enabled by default yet.

canacar> Previously when acpi is enabled in GENERIC, only the parser would be activated so that we can parse and use the interrupt routing tables etc. We did not tell the hardware to actually enable the ACPI mode. Now, after the latest changes, we do.

When the hardware is taken to the ACPI mode, it starts to notify the OS to hardware related events, and expects to be responded properly, by the OS executing the proper AML (ACPI Machine Language) code. Some hardware may stop handling cooling/fans and leave thermal management up to the OS.

From a user's point of view, he will notice that: AC/battery status reporting should work, and so is halt -p and/or the power button.

On the negative side, there is more code running, and users may encounter panics and changes in system behaviour. I would advise users who enable acpi to monitor the system and make sure it is not overheating or having interrupt storms.

toby> I'm hoping that they'll notice things just working better. Unfortunately, that will likely not be the case yet. Many machines will work better with ACPI enabled (especially newer machines), but some will hit on new bugs that enabling ACPI will uncover. The good thing will be that these people can report the bugs [see sendbug(1)] so they can be fixed.

dwc> Are some methods for the OS to identify itself to ACPI better than others, and what are the different results?

beck> You can have different results depending on how you identify yourself — it's not clear which ones will be "better" or "worse" — Identifying yourself as, let's say "Windows NT" may mean the bios will set up things "sanely" to let stuff work with minimal ACPI interference, or it may simply disable devices, or it may try to "work around" OS bugs in the bios. At the moment I don't think we've really come to a firm landing on what we should identify ourselves as, and it isn't always clear there is any one right answer yet. Oh, and there's also more than one way to identify yourself too, just to make things a little more complex.

canacar> All operations and 'functions' in ACPI is written in AML, which is a java-like bytecode, and sometimes too complex. Most AML code has work arounds for different operating system versions (mostly related to ones from Redmond). These AML paths are the most used/tested ones, so should be safer to use.

toby> There are basically two ways for the OS and ACPI to identify each other, plus an extension to the second way. Currently we do our best to use AML code that should implement full ACPI control of the machine.

dwc> Is there new support for significant devices, or perhaps classes of device? How about i386 vs. amd64?

beck> Well, not so much "support for device" as much as "things will work better."

The holy grail is still a working resume (Theo will yell at me for saying that.) That is, the ability to suspend AND RESUME afterwards. But that may take quite a while yet, and frankly, we're not looking at it until some of the other more basic stability and functionality problems are licked.

canacar> Right now you should see thermal zone stuff (temperature sensors, etc.), battery and AC status reporting. You can also enable acpicpu for setting cpu speed through ACPI.

We have to make sure we do not break old devices. If a machine has a working APM we want to keep it working (as most can suspend). Most likely amd64 will get ACPI enabled by default before i386, but it will not be soon.

toby> The reality is that most of this code has been in the tree for some time now, but has not been enabled, or required a full rebuild of a kernel to get it 100% enabled. With the way things are now, simply enabling (using boot -c for example) the acpi device will enable most of the acpi devices.

One of the good things is that some laptops are already being fixed by using the AML interpreter we have. For example, gwk's x60 is much more stable having all the ACPI devices enabled. The wpi(4) works better, halt(8) works correctly with the -p flag, and I'm sure there were other things that worked better with it as well.

dwc> What are the remaining challenges for ACPI support? Does it look like we'll see ACPI enabled by default soon?

beck> The biggest challenges are

  1. Stability (particularly on machines will really crappy AML)
  2. Not interfering with what already works. None of us who have working machines without acpi (either by accident or because APM works) want that to be screwed up by ACPI.

So, please don't view this as an end, but rather (put your churchill hat on) "the end of the beginning" — hopefully with more people using it and sending in useful dmesg and bug reports more progress can be made.

canacar> The best part of this hackathon is that we are now getting real bug reports and are able to fix things now that this code is being tested. I think we got more reports, in the two days after we enabled ACPI in generic then we did in the past two years.

toby> This is a tougher call. We know there are still issues with the current code, and are working hard to try and address those. At the current time it is basically tossing as many different and varied ACPI/AML bios at the current code to stress test all the different code paths. For each bug that is fixed, a whole range of new machines will begin to work.

Thanks to the developers for the great work, and special thanks to Bob Beck for getting everyone together.

As mentioned above, try enabling ACPI, monitor and test, and send your dmesg to dmesg@openbsd.org. That is exactly what's needed to help find what's working and what areas need attention.

(Comments are closed)


Comments
  1. By Anonymous Coward (83.5.224.201) on

    is this work in the last snapshot? I have an asus a6tc with crappy bios/acpi (have tested acpi some since 4.1-current but just drop into ddb). btw, could someone recommend a make of serial-usb adapter so I can get traces easily?

    Comments
    1. By phessler (204.16.153.246) on

      > is this work in the last snapshot? I have an asus a6tc with crappy bios/acpi (have tested acpi some since 4.1-current but just drop into ddb). btw, could someone recommend a make of serial-usb adapter so I can get traces easily?

      serial-usb won't work for getting traces. USB stops in ddb>.


      yes, the code should be in the most recent snapshot, with potentially some more. please try it out, and send in dmesgs!

      Comments
      1. By Anonymous Coward (83.5.224.201) on


        >
        > serial-usb won't work for getting traces. USB stops in ddb>.

        damn ;) cheers.
        >
        >
        > yes, the code should be in the most recent snapshot, with potentially some more. please try it out, and send in dmesgs!

        yeah sure playing with this, have just noticed that boot crash or boot dump will show up in subsequent dmesg.

        Comments
        1. By Damien Miller (djm) on http://www.mindrot.org/~djm/

          > > serial-usb won't work for getting traces. USB stops in ddb>.
          >
          > damn ;) cheers.

          Taking a digital camera shot of the screen works when all else fails.

          Comments
          1. By tedu (38.99.3.113) on

            > > > serial-usb won't work for getting traces. USB stops in ddb>.
            > >
            > > damn ;) cheers.
            >
            > Taking a digital camera shot of the screen works when all else fails.

            and then transcribing it, not posting a grainy 8 meg file to some webpage hosted on a dsl line.

  2. By phessler (204.16.153.246) on

    ferarri? don't make me laugh. my zombie is far more lame than that nicely working machine is! ;)

  3. By Anonymous Coward (207.148.178.250) on

    I'm looking forward to this!

    Any idea what this might do to 10yr old hardware? I've got a P200MMX on 430TX running as a filtered router between two networks...

    Comments
    1. By Anonymous Coward (84.60.84.14) on

      You must be as bored as me now.

    2. By phessler (204.16.153.246) on

      > I'm looking forward to this!
      >
      > Any idea what this might do to 10yr old hardware? I've got a P200MMX on 430TX running as a filtered router between two networks...

      if the P200MMX supports ACPI, then it'll affect you. I highly-highly doubt it does.

      Comments
      1. By Andre (80.127.32.22) andre.van.schoubroeck@gmail.com on

        > > I'm looking forward to this!
        > >
        > > Any idea what this might do to 10yr old hardware? I've got a P200MMX on 430TX running as a filtered router between two networks...
        >
        > if the P200MMX supports ACPI, then it'll affect you. I highly-highly doubt it does.

        I've two computers with an ACPI Socket 7 mainboard. It has a bas ACPI implentation, works in windows 98, but doesn't in windows 2000/xp and linux.

        Will this change make it work on that too now?

        Comments
        1. By sthen (85.158.45.32) on

          > I've two computers with an ACPI Socket 7 mainboard. It has a bas ACPI implentation, works in windows 98, but doesn't in windows 2000/xp and linux.
          >
          > Will this change make it work on that too now?

          There's probably not a lot of advantage to running that particular box with acpi... I'd hazard a guess at it not working; the OS identifies itself to the AML code and I expect the code on your motherboard is probably doing something bad when the OS reported isn't Windows 98. I think you're the only one who can answer that for sure, though :-)

          With the newest snapshots, ACPI is enabled automatically if you have >1 CPU. With 1 CPU reported you would need to just disable APM to get ACPI used.

          Everyone, when you're testing this, search for the newest kernel you can find, and if the standard kernels (without touching ukc to enable/disable anything) now cause problems, detailed reports will be particularly useful.

  4. By Annoying Coward (83.236.54.40) on

    Is there somewhere a database of models whose dmesgs have already been sent in? Or don't you mind having the mailbox fed with redundant information?

    2) My Amilo Pro drops into ddb with acpiec enabled. Since there is no console port (as mentioned some posts above), is there another way to provide useful information?

    Comments
    1. By phessler (204.16.153.246) on

      > Is there somewhere a database of models whose dmesgs have already been sent in? Or don't you mind having the mailbox fed with redundant information?

      if the dmesg has changed, please send it in again.

      >
      > 2) My Amilo Pro drops into ddb with acpiec enabled. Since there is no console port (as mentioned some posts above), is there another way to provide useful information?

      some systems keep the dmesg info available from prior boots. If that isn't available, I type the info in by hand.

    2. By cruel (82.193.99.1) on

      > Is there somewhere a database of models whose dmesgs have already been sent in? Or don't you mind having the mailbox fed with redundant information?
      >
      > 2) My Amilo Pro drops into ddb with acpiec enabled. Since there is no console port (as mentioned some posts above), is there another way to provide useful information?


      You need very fresh -current to see all the changes to ACPI at work. What exact Amilo Pro model do you have?

      Comments
      1. By Anonymous Coward (83.236.54.40) on

        > > Is there somewhere a database of models whose dmesgs have already been sent in? Or don't you mind having the mailbox fed with redundant information?
        > >
        > > 2) My Amilo Pro drops into ddb with acpiec enabled. Since there is no console port (as mentioned some posts above), is there another way to provide useful information?
        >
        >
        > You need very fresh -current to see all the changes to ACPI at work. What exact Amilo Pro model do you have?
        >

        Just sent in the dmesg. It doesn't crash anymore on startup, but complains about critical temperature. w/o acpi everything runs fine.
        It's a FSC Amilo Pro v3505.

  5. By Karl Sjödahl (Dunceor) dunceor@gmail.com on

    This is really nice.
    In my opinion this is one of the most important features on a laptop so it's good it get this much attention.

    Damnit I'm slacking behind on my laptop so I really need to install a new snapshot.

    Great work!

    Comments
    1. By Marc Espie (163.5.254.20) espie@openbsd.org on

      among other things, in case you don't know, quite a few dual core require acpi to work with GENERIC.MP. My new thinkpad is one of those.

      With canacar's work, I started getting battery sensors... it's not quite perfect yet (acpi loses the battery if I remove and reinsert it), but it is getting there !

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.]