DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=sxmPKa+egCcrt40+/N4FrzqOZRCzu9jMP9VqQlYysBYKhlVPgQHRT4wlJ1qj94W1Pb
         BAcdPm5/oOHvm3j9mHvUKrCT7iOrcsisfZ+UNqV6gp/NWiTLZDyd6Jpe1irz+CU8U6Gs
         gaNboRmeW31G7YOT6rsIYcs64DxWGk46FBBDI=
Message-ID: <49693C0A.4070808@gmail.com>
Date: Sat, 10 Jan 2009 16:23:38 -0800
From: "Justin P. Mattock" <justinmattock@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Robert Hancock <hancockr@shaw.ca>
CC: linux-kernel@vger.kernel.org
Subject: Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN
   (4)
References: <49683957.9070700@gmail.com> <49685B70.8080908@shaw.ca> <4968CB72.6080100@gmail.com> <49693720.5010707@shaw.ca>
In-Reply-To: <49693720.5010707@shaw.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2417
Lines: 69

Robert Hancock wrote:
> Justin P. Mattock wrote:
>> Robert Hancock wrote:
>>> Justin P. Mattock wrote:
>>>> I am seeing this in dmesg:
>>>> FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)
>>>> not sure what this is.
>>>> (the only changes to .config was add kexec,
>>>> coredump, and relocatable kernel options.)
>>>>
>>>> I take it that I'm unable to try this relocatable
>>>> kernel stuff out.(x86_32)?
>>>>
>>>> regards;
>>>>
>>>> Justin P. Mattock
>>>
>>> I believe that indicates your BIOS's FADT table contains 
>>> inconsistent data. You're sure that only happens with those options 
>>> set?
>>>
>> Well, the positive side is kexec
>> does work on  macbook pro
>> (doesn't play so well with the xserver,
>> garbled screen.).
>>
>> As for the FADT table, I reverted to an old
>> .config that has no new options in it, and sure enough
>> that message appeared. Looking back in my logs,
>> the last kernel commit I have is:
>> 2.6.28-07485-g9e42d0c
>> that doesn't show such messages.
>>
>> When examining this message
>> (not too familiar with FADT)
>> I see PM leading me to believe this maybe has to
>> do with the PM stuff.
>> (making me wonder, if this is the reason
>> suspend isn't working.just a black screen
>> upon wakeup); but like I said I'm not
>> familiar with that area.
>
> According to the code comments in drivers/acpi/acpica/tbfadt.c:
>
>  * The PM event blocks are split into two register blocks, first is the
>  * PM Status Register block, followed immediately by the PM Enable
>  * Register block. Each is of length (xpm1x_event_block.bit_width/2).
>  *
>  * On various systems the v2 fields (and particularly the bit widths)
>  * cannot be relied upon, though. Hence resort to using the v1 length
>  * here (and warn about the inconsistency).
>
> So it looks like it's fixing things up, so it's not really a problem, 
> just warning about busted BIOS tables. Not impossible it's related to 
> the resume problem, but wouldn't be the first thing I'd look at..
>
Well, as long as the system(or machine)
isn't going to blowup and disintegrate.
I'm fine with that. Thanks for giving me info
on this.

regards;

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/