On Wed, Sep 09, 2020 at 09:15:22AM +0200, Wolfgang Wallner wrote: > -----"Andy Shevchenko" <andy.shevche...@gmail.com> schrieb: ----- > > Betreff: Re: [PATCH v1] cmd: acpi: Print revisions in hex format > > On Tue, Sep 08, 2020 at 05:32:08PM +0200, Wolfgang Wallner wrote: > > > -----"Andy Shevchenko" <andy.shevche...@gmail.com> schrieb: ----- > > > > On Tue, Sep 8, 2020 at 5:58 PM Wolfgang Wallner > > > > <wolfgang.wall...@br-automation.com> wrote: > > > > > -----"Andy Shevchenko" <andriy.shevche...@linux.intel.com> schrieb: > > > > > -----
... > > > > > Related to "acpi list": > > > > > During my recent ACPI debugging I found it very useful to have the > > > > > checksum > > > > > printed for each table with "acpi list". Would there be interest to > > > > > have that > > > > > upstream? If so I would send a patch. > > > > > > > > Can you elaborate what was the problem that checksum helped? > > > > > > Sure. I saw two strange things with the ACPI checksums: > > > > > > 1) The DSDT length included uninitialized bytes from alignment. This is > > > described in the following link: > > > > > > https://lists.denx.de/pipermail/u-boot/2020-September/425378.html > > > > > > This was the actual bug I was looking for. > > > > > > 2) acpi_create_spcr() is missing a memset(). The other acpi_create_xxxx() > > > functions perform a memset on their structure, acpi_create_spcr() does not > > > and as a result the contents of this table are party uninitialized. > > > > > > I plan to send a patch for both of them. > > > > I'm not sure I understood how checksum pointed to uninitialized data? > > After adding the checksums to "acpi list" I realized that the checksums for > DSDT and SPCR where different after every reset. Looking at the code each > turned out to be somehow related to uninitialized memory. I see. I would rather to have it as a separate (sub-)command. But I leave this to Simon. -- With Best Regards, Andy Shevchenko