>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? No, BIOS does not need to be holding the lock. If you can successfully acquire the global lock on the OS side, this will prove that the lock is valid. From the OS, first the "pending" bit is set, and if the global lock is acquired successfully, it responds by setting the "owned" bit. If this works correctly, the global lock works. >-----Original Message----- >From: Zhang, Rui >Sent: Thursday, October 16, 2008 7:47 PM >To: Moore, Robert >Cc: Len Brown; linux-acpi; Lin, Ming M; Zhao, Yakui >Subject: RE: [PATCH 0/6] ACPI: acpi table management enhancement > >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 >> ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
