BTW, I think it is safe and appropriate to conditionally compile the 64-bit SetFirmwareWakingVector interface for inclusion on 64-bit platforms only via: #if ACPI_MACHINE_WIDTH == 64 I'll add this if there are no disagreements. Bob >-----Original Message----- >From: Zhao, Yakui >Sent: Thursday, October 16, 2008 10:15 PM >To: Zhang, Rui >Cc: Moore, Robert; Len Brown; linux-acpi; Lin, Ming M >Subject: RE: [PATCH 0/6] ACPI: acpi table management enhancement > >On Fri, 2008-10-17 at 10:47 +0800, Zhang Rui wrote: >> 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. >In my hand there is another SDV box with the two FACS table. One is >obtained from Firmware_CTRL. Another is obtained from XFirmware_CTRL. >For the FACS pointed by the 32 bit Firmware_CTRL filed: >1) does the 32-bit wake vector work? >Yes. The system can be resumed very well. >2) does the 64-bit wake vector work? > No. The system can't be resumed. > >For the FACS pointed by the 64-bit X_Firmware_CTRL filed: > 1) does the 32-bit wake vector work > Yes. It can be resumed very well. > 2) does the 64-bit wake vector work? > No. It can't be resumed. > >Best regards. > Yakui. >> > >> > >> > >> 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
