OpenBSD Journal

Developer blog: marco

Contributed by marco on from the ACPI-AML-hell dept.

Jordan is sitting at my kitchen table merging the latest incarnation of the AML parser for ACPI. He was on a milage run last weekend and spent 18 hours in the sky. He rewrote large parts of it again due to small but bad enough bugs that existed in the previous versions. This time around all machines that we have selected as test cases seem to build up a correct namespace tree and execute AML correctly. We have found some really bizzare AML code. For example on my amd64, a Tyan 2880, it ran an if statement from physical memory and if that was true it added a root method (e.g. \S4) to the name space. The previous parser was lazy and simply could not deal with such a statement. We tried to hack it up but it was getting so ugly that we decided not to go further down that route. We decided to make the parser stop being a lazy slacker! We are hoping that this new base will allow us to resume working on the ACPI device drivers (famous last words!).

Meanwhile I am working on mpt(4) to add IM support. First thing I did is fixing the debug output. It's too loud and therefore mostly useless; not even mentioning how huge it is! The bad part is that is always compiled in adding too much fluff to the boot floppy. These are the results of that endeavor:

-rw-r--r--  1 root  wheel  16632 Feb  2 21:04 mpt.o
-rw-r--r--  1 root  wheel    469 Feb  2 21:04 mpt_debug.o
-rw-r--r--  1 root  wheel  14356 Feb  2 21:04 mpt_openbsd.o
-rw-r--r--  1 root  wheel   3732 Feb  2 21:04 mpt_pci.o

-rw-r--r--  1 root  wheel  24916 Feb  2 21:44 mpt.o
-rw-r--r--  1 root  wheel  12920 Feb  2 21:44 mpt_debug.o
-rw-r--r--  1 root  wheel  15900 Feb  2 21:44 mpt_openbsd.o
-rw-r--r--  1 root  wheel   3848 Feb  2 21:44 mpt_pci.o

savings: 22395
Not bad for a days work. This is being tested by some others right now to make sure I am not on crack. If this makes it in I'll be able to start adding IM code (now that I can debug it!). After IM I want to add SAS support now that I have the hardware to do so. LSI was so friendly to donate some gear to support this effort. This is going to be done post 3.9 though.

(Comments are closed)

  1. By Anonymous Coward ( on

    A collection of functions for power management, known as the Advanced Configuration and Power Interface (ACPI), has its own high-level interpreted language that could be used to code a rootkit and store key attack functions in the Basic Input/Output System (BIOS) in flash memory, according to John Heasman, principal security consultant for U.K.-based Next-Generation Security Software...

    Continue here:

    1. By Tom Van Looy ( on

      Can this stuff enter your BIOS from (e.g.) Windows and do something ugly to OpenBSD (with no acpi support) when it is on a dual-booted machine?

    2. By Anonymous Coward ( on

      How can we protect against this?

    3. By Marco Peereboom ( on

      This is a really silly advisory.

  2. By rednerd ( on

    Marco - Thank you for all the work you do for the OpenBSD community. I enjoy reading your blog on a regular basis.

    >LSI was so friendly to donate some gear to support this effort. This is >going to be done post 3.9 though.

    If anyone at LSI is reading this, I used up my last Adaptec SCSI card at work yesterday. I will be reordering LSI cards instead of Adaptec. Thanks for the support. :)


  3. By Anonymous Coward ( on

    From my quote request for a machine purchased earlier this week:

    >It looks as though the 3ware cards aren't well-supported on OpenBSD, and
    >from the looks of things, the OpenBSD devs are actually a bit hostile
    >toward them. Do you offer an LSI card on the OpenBSD supported list,
    >like the MegaRAID SATA 150-4?

    1. By Anonymous Coward ( on

      Are you seriously too stupid/lazy to check OpenBSD's i386 hardware compatibility list? (I assume you're smart enough to find the amd64 version given this link). The MegaRAID 150-4 is even listed!

      1. By Anonymous Coward ( on

        And are you too stupid/lazy to understand that this was something he was writing to a vendor, thus prompting said vendor to perhaps consider OpenBSD when making stocking decisions? (I assume you're smart enough to read the comment to which you're replying.)

        1. By Anonymous Coward ( on

          True, anybody sending these messages up the chain through vendors to manufacturers about selecting products based upon the manufacturer's openness to support development on platforms like OpenBSD should be encouraged. Particularly if there are many high volume orders relying upon the support of the manufacturer for open source or open specifications then we need to see this message as often as possible - an open specification community with a reference that is used to influence major hardware purchases is long over due. Sign a few major corporates that won't commit to a manufacturer for 10,000 systems because there is a component in use that is closed in spec and leverage begins.

        2. By Anonymous Coward ( on

          "....thus prompting said vendor to perhaps consider OpenBSD when making stocking decisions..."

          They responded with a new quote with the LSI card in under 10 minutes. It's a popular vendor who specifically states that they provide OpenBSD-compatible machines, which is why I thought it odd that they initially quoted me the 3ware card. It was a $3000 machine, which isn't much in the grand scheme of things, but I wouldn't have purchased it without working with OpenBSD.

      2. By Anonymous Coward ( on

        "The MegaRAID 150-4 is even listed!"

        It certainly is: "LSI/Symbios 523 SATA, MegaRAID 150-4, MegaRAID 150-6, MegaRAID 300-8x"

        And the ami(4) man page lists it as supported:

        "LSI/AMI/Symbios MegaRAID, MegaRAID 320, MegaRAID 320-1, MegaRAID 320-2E, MegaRAID i4, 523 SATA, MegaRAID 150-4, MegaRAID 150-6, MegaRAID 300-8x"

        The initial quote I received included a 3ware card, so I inquired if the vendor stocked an OpenBSD-supported LSI card.

        It couldn't have been much clearer. Marco, then rednerd, then I gave kudos to LSI. Try to follow along, huh?


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