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
> >
>
--
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
