table checksum issues
Len Brown
reviewerBob,
I thought you mentioned the other day that
we never discard a table due to a checksum error. But here is an example of us discarding an SSDT with a bad checksum (and causing cpufreq not to work).
http://bugzilla.kernel.org/show_bug.cgi?id=10513
Did I mis-understand you?
Do you think we should not ignore tables w/ bad checksums in order to be "bug compatible"?
thanks,
-Len
It's a configuration option, at least for the main tables in the RSDT/XSDT. Perhaps not extended to the loaded tables, I will have to look.
Quoted 21 lines
-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Tuesday, May 13, 2008 9:46 PM
To: Moore, Robert
Cc: [email protected]
Subject: table checksum issuesBob,
I thought you mentioned the other day that
we never discard a table due to a checksum error. But here is an example of us discarding an SSDT with a bad checksum (and causing cpufreq not to work).http://bugzilla.kernel.org/show_bug.cgi?id=10513
Did I mis-understand you?
Do you think we should not ignore tables w/ bad checksums in order to be "bug compatible"?thanks,
-Len
Yes, it is optional for all tables. The code is below. If there is no AE_BAD_CHECKSUM exception, the table load has not been aborted.
if (Checksum)
{
ACPI_WARNING ((AE_INFO,
"Incorrect checksum in table [%4.4s] - %2.2X, should be
%2.2X",
Table->Signature, Table->Checksum, (UINT8) (Table->Checksum
- Checksum)));
#if (ACPI_CHECKSUM_ABORT)
return (AE_BAD_CHECKSUM);
#endif
}Default behavior is to ignore checksum errors, just print the warning:
/*
* Should the subsystem abort the loading of an ACPI table if the
* table checksum is incorrect?
*/
#define ACPI_CHECKSUM_ABORT FALSE
Quoted 8 lines
-----Original Message-----
From: Moore, Robert
Sent: Tuesday, May 13, 2008 10:01 PM
To: 'Len Brown'
Cc: [email protected]
Subject: RE: table checksum issuesIt's a configuration option, at least for the main tables in the
RSDT/XSDT.
Quoted 24 lines
Perhaps not extended to the loaded tables, I will have to look.
Quoted 21 lines
-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Tuesday, May 13, 2008 9:46 PM
To: Moore, Robert
Cc: [email protected]
Subject: table checksum issuesBob,
I thought you mentioned the other day that
we never discard a table due to a checksum error. But here is an example of us discarding an SSDT with a bad checksum (and causing cpufreq not to work).http://bugzilla.kernel.org/show_bug.cgi?id=10513
Did I mis-understand you?
Do you think we should not ignore tables w/ bad checksums in order to be "bug compatible"?thanks,
-Len
Quoted 13 lines · Robert
Yes, it is optional for all tables. The code is below. If there is no
AE_BAD_CHECKSUMexception, the table load has not been aborted.if (Checksum)
{
ACPI_WARNING((AE_INFO,
"Incorrect checksum in table [%4.4s] - %2.2X, should be
%2.2X",Table->Signature, Table->Checksum, (UINT8) (Table->Checksum- Checksum)));
Quoted 7 lines
#if (ACPI_CHECKSUM_ABORT) return (AE_BAD_CHECKSUM); #endif }Default behavior is to ignore checksum errors, just print the warning:
What Bob said is right. Now only warning message is printed when the checksum is bad.
On the laptop of bug 10513 the SSDT table is still loaded when the checksum is bad. And the problem is that there is an error in the _PDC object(CPU0) , which causes that some extra SSDT tables can't be loaded dynamically .(For example: P-state, C-state). So after the system is booted, the cpufreq driver can't work.
Quoted 45 lines
/*
* Should the subsystem abort the loading of an ACPI table if the
* table checksum is incorrect?
*/
#defineACPI_CHECKSUM_ABORTFALSEQuoted 8 lines
-----Original Message-----
From: Moore, Robert
Sent: Tuesday, May 13, 2008 10:01 PM
To: 'Len Brown'
Cc: [email protected]
Subject: RE: table checksum issuesIt's a configuration option, at least for the main tables in the
RSDT/XSDT.
Quoted 24 lines
Perhaps not extended to the loaded tables, I will have to look.
Quoted 21 lines
-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Tuesday, May 13, 2008 9:46 PM
To: Moore, Robert
Cc: [email protected]
Subject: table checksum issuesBob,
I thought you mentioned the other day that
we never discard a table due to a checksum error. But here is an example of us discarding an SSDT with a bad checksum (and causing cpufreq not to work).http://bugzilla.kernel.org/show_bug.cgi?id=10513
Did I mis-understand you?
Do you think we should not ignore tables w/ bad checksums in order to be "bug compatible"?thanks,
-Len--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html