On Wed, 2008-10-15 at 16:21 -0600, Moore, Robert wrote: > 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? yes > 2) does the 64-bit wake vector work? no. reboot upon resume. > 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? no. reboot upon resume. > 2) does the 64-bit wake vector work? no. reboot upon resume. well, we got a total different result on another box with two FACS tables, yakui will update later. > 3) does the global lock work? > In order to test if global lock works or not, we need to acquire the global lock in Linux while BIOS holds it, right? But I don't know how to make BIOS hold the global lock. :( any ideas? thanks, rui > > >-----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 > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
