As usual with ACPI issues, the more we dig, the worse the problem gets: Another potential problem is the Global Lock. If there are two FACS tables, it is probably the case that the Global Lock only works with one of the tables. Please check on your machine if the global lock is working or not. If it is the case that both the Firmware Waking Vector and the Global Lock work with only one of the FACS tables, it would probably be best to determine which one of the tables is the "real" FACS and just use that one (rather than use two tables.) To determine the "real" FACS, at initialization time we could try to obtain the global lock -- and only the real table will get a response from the BIOS. I hope it is beyond imagination that a BIOS would be implemented such that the Global Lock is implemented in one table, and the Firmware Waking Vector is implemented in another. Bob >-----Original Message----- >From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >owner@xxxxxxxxxxxxxxx] On Behalf Of Moore, Robert >Sent: Tuesday, October 14, 2008 2:13 PM >To: Zhang, Rui >Cc: Len Brown; linux-acpi; Lin, Ming M >Subject: RE: [PATCH 0/6] ACPI: acpi table management enhancement > >So, this apparently comes down to a problem where the FADT contains two >different addresses for the FACS in the FIRMWARE_CTRL and X_FIRMWARE_CTRL >fields. It would be a relatively simple fix to write the wake vector to >both tables if necessary. I don't see a need to go back to the RSDT for >this case. > > >A couple of global comments: > >1) In general, it seems like a lot of overhead to load a second set of >"inactive" tables from the RSDT -- especially if this is for debug only. >Not only the code to do it, but the dynamic memory for the second root >table list and the memory mappings, potentially one for each table in the >RSDT. > >2) As far as acpidump -- I have plans to enhance this utility so that it is >OS-independent and will run on any host. The current version of acpidump is >Linux-specific. So, I don't think acpidump is going away. If we need a dump >of both the XSDT tables and the RSDT tables, we should be able to modify >acpidump to perform this, and we will not need to add kernel code or use >kernel resources. > >Bob > > >>-----Original Message----- >>From: Zhang, Rui >>Sent: Monday, October 13, 2008 6:01 PM >>To: Moore, Robert >>Cc: Len Brown; linux-acpi >>Subject: RE: [PATCH 0/6] ACPI: acpi table management enhancement >> >>On Mon, 2008-10-13 at 11:02 -0600, Moore, Robert wrote: >>> >I found that there are two FACS tables on this platform, >>> >XSDT-->FADT1-->Xfacs-->FACS1 >>> > |----->facs-| >>> > |->FACS2 >>> >RSDT-->FADT2-->facs-| >>> >Linux uses XSDT on this platform and sets the waking vector in FACS1 >>> >when suspending. >>> >But it seems that the BIOS only cares for the waking vector in FACS2, >>> >>> >>> Is this possibly an issue of using the 32-bit wake vector versus the 64- >>bit wake vector? (For example, perhaps the FACS1 has both vectors and the >>64-bit vector is used but fails. But the FACS2 only has the 32-bit vector >>so it is used, and this works correctly with the BIOS.) >>No, I tested the patch from Rafael, which is the same from the one >>here: >>http://www.acpica.org/bugzilla/attachment.cgi?id=813&action=view >>It doesn't work. >> >>> Or, is it actually the case where the two FACS tables have different >wake >>vectors? Both the 32-bit vectors and the 64-bit vectors are different? >>the wake vector is just a memory address where BIOS passes the control >>to OS. >>As there are two different FACS tables located at different addresses, >>surely the wake vectors are different. :) >> >>thanks, >>rui >> >N�����r��y���b�X��ǧv�^�){.n�+����{�i�b�{ay� ʇڙ�,j ��f���h���z� �w��� >���j:+v���w�j�m���� ����zZ+�����ݢj"��!�i ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
