ACPI Shutdown doesn't work

[cklie97]

Recently I implemented code for the acpi subsystem. I got this code from http://forum.osdev.org/viewtopic.php?t=16990.

After some several testing I tested this on real hardware. But instead of shutting down the PC performed a boot after the ending of shutdown.

Another problem is that I have the same problem as discribed in http://f.osdev.org/viewtopic.php?t=30623 but I do not get what "PM1_EN" is or where I can find it.

So I am asking for help.

[Brendan]

Hi,

Recently I implemented code for the acpi subsystem. I got this code from http://forum.osdev.org/viewtopic.php?t=16990.

After some several testing I tested this on real hardware. But instead of shutting down the PC performed a boot after the ending of shutdown.

Another problem is that I have the same problem as discribed in http://f.osdev.org/viewtopic.php?t=30623 but I do not get what "PM1_EN" is or where I can find it.

So I am asking for help.

On a scale from 1 to 10, where 1 represents "works sometimes on some computers if you're extremely lucky" and where 10 represents "complies with all relevant standards, avoids all possible pitfalls, and is guaranteed to always work on any computer that has ACPI if the firmware isn't buggy", the code in that topic should never be used.

There are only 4 possible choices:

• don't touch anything that involves ACPI's AML at all (and let firmware handle everything itself)
• implement a full AML interpreter for everything including power management and fan control, IRQ routing, sleep states, button management, etc (which can mean porting ACPICA)
• implement a motherboard driver for every motherboard you support, which does everything that a full AML interpreter would've done
• suffer consequences ranging from unreliability/instability to hardware damage

Cheers,

Brendan

[bzt]

...or forget about messy ACPICA, and use a small and clean implementation instead. At least that's what OpenBSD does:
https://github.com/openbsd/src/blob/mas ... cpi/acpi.c
https://github.com/openbsd/src/blob/mas ... cpi/dsdt.c

Code: Select all

 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.

[Korona]

I wonder what the better choice is: Porting 10000+ SLOC of "small and clean" (aka undocumented) OpenBSD code or using an library that is written by Intel and actually has documentation. NIH syndrome?

(I don't think that ACPICA is great and I plan to eventually get rid of it and write an own AML interpreter but it is still probably the best solution that exists today.)

[SpyderTL]

I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.

You could dump the AML byte codes from your ACPI table, and decompile it, or just walk through it step by step and see what it does. Then check your code and make sure it makes the correct OUT calls with the correct values.

EDIT: Who has two thumbs, and five stars?? THIS GUY!!!

[Brendan]

Hi,

I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.

You could dump the AML byte codes from your ACPI table, and decompile it, or just walk through it step by step and see what it does. Then check your code and make sure it makes the correct OUT calls with the correct values.

EDIT: Who has two thumbs, and five stars?? THIS GUY!!!

Now that you've finally reached 5 stars; it's time to ask the important question: How long has your "adequate temporary solution" been permanently "temporary" so far?


Cheers,

Brendan

[LtG]

I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.

Now that you've finally reached 5 stars; it's time to ask the important question: How long has your "adequate temporary solution" been permanently "temporary" so far?

Isn't it the same solution you suggested, MoBo driver? Just slightly different terminology and needed encapsulation. I plan on using MoBo drivers as well, simply because it means I can bypass certain things that aren't interesting and provide no direct benefit now, only provide wider hardware support.

Also, it has the nice feature of allowing easy way out once/if I ever get to around implementing ACPI/AML/ACPICA, since those would effectively make for a generic MoBo driver..

[Brendan]

Hi,

I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.

Now that you've finally reached 5 stars; it's time to ask the important question: How long has your "adequate temporary solution" been permanently "temporary" so far?

Isn't it the same solution you suggested, MoBo driver? Just slightly different terminology and needed encapsulation. I plan on using MoBo drivers as well, simply because it means I can bypass certain things that aren't interesting and provide no direct benefit now, only provide wider hardware support.

Also, it has the nice feature of allowing easy way out once/if I ever get to around implementing ACPI/AML/ACPICA, since those would effectively make for a generic MoBo driver..

In general (potentially excluding learning); I go with the "nothing is better than something not done right" theory. The idea is that temporary code ("good enough for now") removes most of the incentive to find/create a correct solution and ends up becoming "permanently temporary" because there's always something more urgent or more interesting; and as time passes you end up just adding more temporary code, hacks and work-arounds until you reach a point where the slightest breeze causes the entire tower to crumble.

My "motherboard drivers, no ACPI" plan means that there's a lot of incentive to create motherboard drivers (no IO APIC or MSI, no power management, no software power off, no fan control, no temperature sensors, etc). It's also idealistic and not necessarily practical (and not something I'd recommend to others), but does give me the option of allowing/using a generic motherboard driver that implements "full ACPI done right" if sacrifices must be made.

Of course part of the reason for the "motherboard drivers, no ACPI" plan is that it allows me to require support for things that ACPI doesn't have (being able to prevent malicious tampering via. digital signatures, including "SMBIOS like" information to get rid of another firmware mess, having 3D models so maintenance people can see where parts are before/without opening the case, etc) and then be able to claim that for supported computers (computers that have a motherboard driver) the OS is superior to every other OS that can't do any of these things because they're limited to what Microsoft wanted added to the ACPI specs.


Cheers,

Brendan

[Korona]

In general (potentially excluding learning); I go with the "nothing is better than something not done right" theory. The idea is that temporary code ("good enough for now") removes most of the incentive to find/create a correct solution and ends up becoming "permanently temporary" because there's always something more urgent or more interesting; and as time passes you end up just adding more temporary code, hacks and work-arounds until you reach a point where the slightest breeze causes the entire tower to crumble.

I think this is just a project management issue. My usual workflow is: Designing a new feature (this takes up most of the time) -> looking at the old code that is affected by it -> refactoring the old code until it is good enough to add the new feature without major hacks/workarounds -> actually implement the feature -> test the feature and its interactions with existing stuff -> refactor the new code until it passes code review. I rarely if ever run into a "slightest breeze that cause the entire tower to crumble", neither at work nor at my hobby projects.

Always getting it right on the first try is not a viable strategy.

[LtG]

In general (potentially excluding learning); I go with the "nothing is better than something not done right" theory. The idea is that temporary code ("good enough for now") removes most of the incentive to find/create a correct solution and ends up becoming "permanently temporary" because there's always something more urgent or more interesting; and as time passes you end up just adding more temporary code, hacks and work-arounds until you reach a point where the slightest breeze causes the entire tower to crumble.

Hardcoding stuff into the MoBo/CPU/Platform/etc drivers is fine for me, since it means I can proceed with the more important/interesting stuff, but does mean that each device will need a driver to function. Later, if there's reason for it, I can create generic versions as well and nothing else will need to be changed.

So as long as the functionality is encapsulated in the right place there's no problem. Putting hacks all over the code is of course a bad idea and will lead to the "entire tower crumbling".

Note also that you mentioned "done right", of course what I'm suggesting is assuming that what the driver does is "right", even if not generic, so using "magic numbers" such as knowledge of specific IO ports for specific MoBo is fine, doing random stuff and hoping for best obviously isn't. But as said, such MoBo driver isn't generic and will require a separate driver for each MoBo I want to support, but also means that I can postpone ACPI/AML until I need it for generic MoBo's, because generic is less effort than adding yet another specific MoBo driver, and that might never happen =)