Stefan,
It seems that you put some code about acpi in the tree.
What's your plan about that?
Can I use that together with ACPI support in Kernel to make "shutdown -h now" to be real shutdown the power?
Regards
YH
* YhLu YhLu@tyan.com [040311 06:14]:
Stefan,
It seems that you put some code about acpi in the tree.
What's your plan about that?
I created some basic framework for dynamic ACPI table creation, but it is by no means a complete ACPI implementation. Plan is to also support powermanagement on AMD64 (and hopefully get ACPI going for other ports as well)
Can I use that together with ACPI support in Kernel to make "shutdown -h now" to be real shutdown the power?
Currently, no. Not all information is provided by LinuxBIOS yet to make this work. (Much of it can be generated from the device tree) The ACPI implementation currently only allows to utilize the HPET timer in Linux (which is not possible without ACPI at all)
Stefan
As it happens the real important thing (which we hope to get to) is SRAT tables, so that Linux with NUMA support will work on K8.
Yep, it really matters, as somebody from IBM explained to me recently.
ron
ron minnich rminnich@lanl.gov writes:
As it happens the real important thing (which we hope to get to) is SRAT tables, so that Linux with NUMA support will work on K8.
Yep, it really matters, as somebody from IBM explained to me recently.
On K8 with a 64bit NUMA kernel it should not matter, because the kernel can look and see where everything is.
In the general case or with a 32bit kernel is makes sense. I believe the SRAT table is not an AML table so it really should not be hard to accommodate.
Eric
On 11 Mar 2004, Eric W. Biederman wrote:
On K8 with a 64bit NUMA kernel it should not matter, because the kernel can look and see where everything is.
well, according to the ibm guys, linux does not know how to find out where physical dram (i.e. which CPU) is attached on K8 without SRAT. If you're saying they may be wrong, I'm happy.
ron
YhLu YhLu@tyan.com writes:
Stefan,
It seems that you put some code about acpi in the tree.
What's your plan about that?
Currently ACPI support exists simply to provide the extra ACPI tables. No AML currently exists.
We need to get enough IRQ information in the device tree so we can auto generate these kinds of tables.
Can I use that together with ACPI support in Kernel to make "shutdown -h now" to be real shutdown the power?
That would not be the worst thing to implement. However we have not gone there yet.
If the BIOS has to implement services an interpreted byte code where the kernel provides the interpreter at least gives the kernel guys the option of catching bugs, and working around them. I completely prefer AML over BIOS callbacks.
Is AML turing complete?
It would be nice if the hardware was standardized enough that simple things like this were architectural instead of needing BIOS work.
Eric
On 11 Mar 2004, Eric W. Biederman wrote:
If the BIOS has to implement services an interpreted byte code where the kernel provides the interpreter at least gives the kernel guys the option of catching bugs, and working around them. I completely prefer AML over BIOS callbacks.
YES!
Is AML turing complete?
I am sure it is. I am sure that it would be able to pass the Turing test, it is so complex :-)
ron
* ron minnich rminnich@lanl.gov [040311 15:16]:
On 11 Mar 2004, Eric W. Biederman wrote:
If the BIOS has to implement services an interpreted byte code where the kernel provides the interpreter at least gives the kernel guys the option of catching bugs, and working around them. I completely prefer AML over BIOS callbacks.
YES!
In case of broken 16bit bioses there might be a point. But for us I don't really see the difference. If it's broken, we can fix it. Even when using callbacks, can't we?
Stefan
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [040311 15:16]:
On 11 Mar 2004, Eric W. Biederman wrote:
If the BIOS has to implement services an interpreted byte code where the kernel provides the interpreter at least gives the kernel guys the option of catching bugs, and working around them. I completely prefer AML over BIOS callbacks.
YES!
In case of broken 16bit bioses there might be a point. But for us I don't really see the difference. If it's broken, we can fix it. Even when using callbacks, can't we?
We should. An installed BIOS has an amazing amount of initeria if it is some little thing.
With AML you can load a new version from the OS without having to flash you BIOS so it is safer.
Plus there are issues of needed multiple entry points 32bit 64bit and possibly 16bit depending on which mode the processor is operating in. With byte code you only need to provide one version.
Basically byte code seems much more optional than a magic function you can call. But in the practical it should be possible to fix the firmware, and reflash if we did provide callbacks. I just like to err as far as possible on the side of caution.
My preference is to provide no code that is run after the OS loads, and just to specify some static table entries. The rest is essentially a fallback position.
Eric
On 11 Mar 2004, Eric W. Biederman wrote:
Basically byte code seems much more optional than a magic function you can call. But in the practical it should be possible to fix the firmware, and reflash if we did provide callbacks. I just like to err as far as possible on the side of caution.
and byte code you can call is probably bad for keeping the processor cache, TLBs, etc. nice and current.
My preference is to provide no code that is run after the OS loads, and just to specify some static table entries. The rest is essentially a fallback position.
yep.
ron
-
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer -
YhLu