The 2.6.27 have less issues, though the FADT issues seems to be identical. I'll attach the dmesg from 27 here. [ 0.000000] ACPI Error (tbfadt-0453): 32/64X address mismatch in "Gpe0Block": [0000F820] [000000000001F028], using 64X [20080609] Is same what I saw in 28, but the only error, I see more in 28. [ 2.662287] usplash[1202]: segfault at c1a7c ip 00001a7c sp 00000ffa error 15 in zero (deleted)[1000+9f000] Didn't see this one in 28. :-) -----Original Message----- From: Matthew Garrett [mailto:mjg59@xxxxxxxxxxxxx] Sent: Wednesday, December 03, 2008 3:36 PM To: Moore, Robert Cc: Koornstra, Reinoud; linux-acpi@xxxxxxxxxxxxxxx; Brown, Len; Lin, Ming M Subject: Re: 2.6.28-rc7 acpi error messages On Wed, Dec 03, 2008 at 03:12:55PM -0800, Moore, Robert wrote: > Not even the 32-bit values seem fully correct, however. For example: > > [05Ch 092 1] GPE0 Block Length : 10 > > > [0DCh 220 12] GPE0 Block : <Generic Address Structure> > [0DCh 220 1] Space ID : 01 (SystemIO) > [0DDh 221 1] Bit Width : 20 > [0DEh 222 1] Bit Offset : 00 > [0DFh 223 1] Access Width : 00 > [0E0h 224 8] Address : 000000000001F028 > > > For the first block length, I seriously doubt that the machine has (0x10 * 8) = 128 GPEs. The bit width of 0x20 (32 GPEs) sounds more reasonable. Hmm, indeed - Intel hardware only decodes 32-bits for the GPE block. Do we have the version 1 FADT from the machine as well? If that's correct it suggests that Windows gets all of this information from there rather than using the version 2 table at all, while if it isn't perhaps we need to take the width from the 64-bit values. Sigh. What a mess. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx
Attachment:
27-DMESG_OUTPUT
Description: 27-DMESG_OUTPUT
