First Cup of Ubuntu
Thanks for your work, but the problem i still there.
The machine goes down in the suspend for approximately 2 seconds and than it goes up and you can work. Now i believe that Lenovo did a hack that only Windows Home Server works very well.
Bye and a nice week-end.
Spilled the Beans
The problem could be another ACPI table. Too many people focus solely on the DSDT. If the FACP and SSDT tables are incorrect then these could cause a conflict with power savings implementations. I would disassemble and compile each of the ACPI tables for your specific platform. Try to debug those for any errors.
Originally Posted by bymaxe
First Cup of Ubuntu
Thanks for the support! I had already moved back to Windows, however I'll give Ubuntu another try with the DSDT supplied by you.
KR, Erik
First Cup of Ubuntu
Hi,
On my Dell Vostro I am having problems with power management. After dumping all my ACPI tables I see that one of my SSDT tables (attached) is buggy and will not compile.
I'd be very grateful if you'd take a look at it for me please. This SSDT contains the Scope (_PR) info. that more usually appears in DSDTs I think.
Thank you.
Spilled the Beans
This SSDT has three declared externals, probably declared in the DSDT, and no defined arguments. If you'll look at the declared external object and the arguments assigned in the definition block then ask yourself, "What is accomplished?" The arguments aren't defined anywhere and if they are then it is external. Also, in order to assign arguments, wouldn't you agree that you would need to create fields for them and be able to store them in a variable. I interpret this SSDT as broken without having the external reference available to correct what is probably duplicated externally so this would mean it is redundant. Another thing, whenever I inspected your header for this table before the first compile, it was pointing to the dsdt.aml, so I would believe that this table must have been extracted from the DSDT, unless you had caused the wrong naming convention. Anyways, nothing can be done without more information or since in the tables current state, it accomplishes nothing, then you could exclude it.
Look up the processor configuration in Section 8 of the latest ACPI 4.0 specification and you would be able to have a reference as to what should be declared for the processor in the _PR scope. BTW, How did you obtain this SSDT table? I hope it wasn't from copying and pasting directly from the ACPI binary module. If you miss one byte or if the table is broken up throughout the ACPI binary then this table is useless.
Last edited by computer.technician; June 28th, 2010 at 06:06 PM. Reason: Reference to important information
First Cup of Ubuntu
Hi,
Thanks for the reply. It was extracted in the usual way from Linux.....as a reference, I have attached the zip file of the original full table extraction. The DSDT as original has a few warnings etc. but nothing radically strange.
Spilled the Beans
I'll try to read through the tables whenever I get some free time but I've got quite alot that I'm having to complete for work this week. What troubleshooting have you attempted in debugging the tables?
First Cup of Ubuntu
It's really the processor declarations I would like to try and sort out.
I use the laptop in Ubuntu, Windows 7, but also in OSX and for OSX I'd like to be able to have the _PR statements all incorporated into the DSDT. I don't know how to do that in this specific case because the DSDT Scope (_PR) parts seem to require the use of the SSDT tables - and the SSDT tables from this board and how they interact with the DSDT make no sense to me.
So if you get any time to help, then it is the _PR statement parts - preferably with a view to integration of ssdt into dsdt - that'd really be helpful for me.
Thank you for your help.
Spilled the Beans
I noticed that your submitted SSDT and DSDT were retrieved in a Mac environment; correct? Have you patched your ACPI tables or is this the manufacturer supplied tables? If the firmware contains the manufacturer supplied tables then are you using a patched DSDT for the Mac OS to boot up? I'm only attempting to patch the original tables for any inconsistent AML and not for Darwin. Retrieve the ACPI tables within a Linux environment by using acpidump and acpixtract after reverting the platform firmware to its manufacturers state. There are other forums for hacking firmware to support the Mac OS kernel.
What's the model or service tag # of the Dell Vostro? I'll download the BIOS from the Dell support site and extract the ACPI module.
Last edited by computer.technician; June 28th, 2010 at 10:30 PM. Reason: Inquiring about the Make/Model
First Cup of Ubuntu
Hi,
No actually they were taken direct from a linux environment using an acpi-dump python script from a live Opensuse CD (i.e. using the acpidump tool). Yes, I have opened in a mac environment, but what i sent to you were the originals from the linux extraction........they are the manufacturer supplied and unpatched tables,
The Dell Vostro is a 3500 running latest Bios of A04.
Please though if you feel that there is something amiss then feel free to download again.
I have been doing patching, but not at all to the tables i supplied to you - they are 100% as Dell made them. I would not ask for Darwin patching here, but am grateful for any help that you feel able to give me with what look to me to be slightly odd examples and in particular with the _PR scope issue.
Thanks again.
Posting Permissions
Adv Reply
Bookmarks