Rui, We need to find out *exactly* what is going on with this machine before we do any coding. Here is what we need to know: For the FACS pointed to by the 32-bit FIRMWARE_CTRL field: 1) does the 32-bit wake vector work? 2) does the 64-bit wake vector work? 3) does the global lock work? For the FACS pointed to by the 64-bit X_FIRMWARE_CTRL field: 1) does the 32-bit wake vector work? 2) does the 64-bit wake vector work? 3) does the global lock work? >-----Original Message----- >From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >owner@xxxxxxxxxxxxxxx] On Behalf Of Moore, Robert >Sent: Wednesday, October 15, 2008 3:13 PM >To: Zhang, Rui >Cc: Len Brown; linux-acpi; Lin, Ming M >Subject: RE: [PATCH 0/6] ACPI: acpi table management enhancement > >While we are trying to determine which is the "real" FACS, there is one >more goofy possibility that we should probably explore: > >How about if: > >1) the 64-bit X_FIRMWARE_WAKING_VECTOR is implemented in the FACS that is >pointed to by the 64-bit X_FIRMWARE_CTRL field in the FADT, and > >2) the 32-bit FIRMWARE_WAKING_VECTOR is implemented in the other FACS, the >one pointed to by the 32-bit FIRMWARE_CTRL field in the FADT. > >This could be the mistake in reasoning that led to the two different FACS >tables in the first place. > >If this is true, then which FACS has the valid Global Lock? > > > >>-----Original Message----- >>From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >>owner@xxxxxxxxxxxxxxx] On Behalf Of Moore, Robert >>Sent: Wednesday, October 15, 2008 1:56 PM >>To: Zhang, Rui >>Cc: Len Brown; linux-acpi; Lin, Ming M >>Subject: RE: [PATCH 0/6] ACPI: acpi table management enhancement >> >>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��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
