* table checksum issues @ 2008-05-14 4:46 Len Brown 2008-05-14 5:00 ` Moore, Robert 2008-05-14 5:19 ` Moore, Robert 0 siblings, 2 replies; 4+ messages in thread From: Len Brown @ 2008-05-14 4:46 UTC (permalink / raw) To: Moore, Robert; +Cc: linux-acpi Bob, 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: table checksum issues 2008-05-14 4:46 table checksum issues Len Brown @ 2008-05-14 5:00 ` Moore, Robert 2008-05-14 5:19 ` Moore, Robert 1 sibling, 0 replies; 4+ messages in thread From: Moore, Robert @ 2008-05-14 5:00 UTC (permalink / raw) To: Len Brown; +Cc: linux-acpi 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. >-----Original Message----- >From: Len Brown [mailto:lenb@kernel.org] >Sent: Tuesday, May 13, 2008 9:46 PM >To: Moore, Robert >Cc: linux-acpi@vger.kernel.org >Subject: table checksum issues > >Bob, >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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: table checksum issues 2008-05-14 4:46 table checksum issues Len Brown 2008-05-14 5:00 ` Moore, Robert @ 2008-05-14 5:19 ` Moore, Robert 2008-05-14 8:49 ` Zhao Yakui 1 sibling, 1 reply; 4+ messages in thread From: Moore, Robert @ 2008-05-14 5:19 UTC (permalink / raw) To: Moore, Robert, Len Brown; +Cc: linux-acpi 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 >-----Original Message----- >From: Moore, Robert >Sent: Tuesday, May 13, 2008 10:01 PM >To: 'Len Brown' >Cc: linux-acpi@vger.kernel.org >Subject: RE: table checksum issues > >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. > > >>-----Original Message----- >>From: Len Brown [mailto:lenb@kernel.org] >>Sent: Tuesday, May 13, 2008 9:46 PM >>To: Moore, Robert >>Cc: linux-acpi@vger.kernel.org >>Subject: table checksum issues >> >>Bob, >>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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: table checksum issues 2008-05-14 5:19 ` Moore, Robert @ 2008-05-14 8:49 ` Zhao Yakui 0 siblings, 0 replies; 4+ messages in thread From: Zhao Yakui @ 2008-05-14 8:49 UTC (permalink / raw) To: Moore, Robert; +Cc: Len Brown, linux-acpi On Tue, 2008-05-13 at 22:19 -0700, Moore, Robert wrote: > 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: 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. > /* > * Should the subsystem abort the loading of an ACPI table if the > * table checksum is incorrect? > */ > #define ACPI_CHECKSUM_ABORT FALSE > > > > >-----Original Message----- > >From: Moore, Robert > >Sent: Tuesday, May 13, 2008 10:01 PM > >To: 'Len Brown' > >Cc: linux-acpi@vger.kernel.org > >Subject: RE: table checksum issues > > > >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. > > > > > >>-----Original Message----- > >>From: Len Brown [mailto:lenb@kernel.org] > >>Sent: Tuesday, May 13, 2008 9:46 PM > >>To: Moore, Robert > >>Cc: linux-acpi@vger.kernel.org > >>Subject: table checksum issues > >> > >>Bob, > >>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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-05-14 8:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-14 4:46 table checksum issues Len Brown 2008-05-14 5:00 ` Moore, Robert 2008-05-14 5:19 ` Moore, Robert 2008-05-14 8:49 ` Zhao Yakui
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox