On Sun, Jul 14, 2013 at 09:12:42PM -0400, Kevin O'Connor wrote:
On Fri, Jul 12, 2013 at 10:08:01AM +0800, Hu Tao wrote:
On Sun, Jul 07, 2013 at 11:42:40PM -0400, Kevin O'Connor wrote:
On Wed, Jul 03, 2013 at 05:59:07PM +0800, Hu Tao wrote:
Currently the calculation of PkgLength isn't acpi-compliant. This patch fixes it to be acpi-compliant.
What isn't acpi compliant with the current calculation?
Currently, the length of PkgLength itself is hard-coded(third parameter of encodeLen). If the length of PkgLength must have strictly the relationship with package length as follow as in ACPI specification:
package length PkgLength 0-63 1 byte 64-4096(2^12) 2 bytes 4097-1048576(2^20) 3 bytes
1048576 4 bytes
then current calculation is not acpi-compliant. But if not, say, a 4-byte PkgLength can legally encode a 10-byte package, then current calculation is acpi-compliant.
My read of the spec was that one can always use a larger length encoding than needed. I haven't seen any issues with it in my tests. Can you confirm that the length encoding is causing problems for you?
You're right. I confirmed that the cause of Windows BSOD is wrong hard-coded package length, not bytes of PkgLength.