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
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?
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.
heres what I see:
[ 0.000000] ACPI: RSDP 000FE020, 0024 (r2 APPLE )
[ 0.000000] ACPI: XSDT 3FEFD1C0, 0074 (r1 APPLE Apple00
A5 1000013)
[ 0.000000] ACPI: FACP 3FEFB000, 00F4 (r3 APPLE Apple00 A5
Loki 5F)
[ 0.000000] FADT: X_PM1a_EVT_BLK.bit_width (16) does not match
PM1_EVT_LEN (4)
[ 0.000000] ACPI: DSDT 3FEF0000, 48D1 (r1 APPLE MacBookP 20002
INTL 20050309)
[ 0.000000] ACPI: FACS 3FEC0000, 0040
[ 0.000000] ACPI: HPET 3FEFA000, 0038 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: APIC 3FEF9000, 0068 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: MCFG 3FEF8000, 003C (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: ASF! 3FEF7000, 00A0 (r32 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: SBST 3FEF6000, 0030 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: ECDT 3FEF5000, 0053 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: SSDT 3FEEF000, 04DC (r1 APPLE CpuPm 3000
INTL 20050309)
[ 0.000000] ACPI: SSDT 3FEBD000, 064F (r1 SataRe SataPri 1000
INTL 20050309)
[ 0.000000] ACPI: SSDT 3FEBC000, 069C (r1 SataRe SataSec 1000
INTL 20050309)
[ 0.000000] ACPI: Local APIC address 0xfee00000
and looking at
2.6.28-07485-g9e42d0c
[ 0.000000] ACPI: RSDP 000FE020, 0024 (r2 APPLE )
[ 0.000000] ACPI: XSDT 3FEFD1C0, 0074 (r1 APPLE Apple00
A5 1000013)
[ 0.000000] ACPI: FACP 3FEFB000, 00F4 (r3 APPLE Apple00 A5
Loki 5F)
[ 0.000000] ACPI: DSDT 3FEF0000, 48D1 (r1 APPLE MacBookP 20002
INTL 20050309)
[ 0.000000] ACPI: FACS 3FEC0000, 0040
[ 0.000000] ACPI: HPET 3FEFA000, 0038 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: APIC 3FEF9000, 0068 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: MCFG 3FEF8000, 003C (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: ASF! 3FEF7000, 00A0 (r32 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: SBST 3FEF6000, 0030 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: ECDT 3FEF5000, 0053 (r1 APPLE Apple00 1
Loki 5F)
[ 0.000000] ACPI: SSDT 3FEEF000, 04DC (r1 APPLE CpuPm 3000
INTL 20050309)
[ 0.000000] ACPI: SSDT 3FEBD000, 064F (r1 SataRe SataPri 1000
INTL 20050309)
[ 0.000000] ACPI: SSDT 3FEBC000, 069C (r1 SataRe SataSec 1000
INTL 20050309)
[ 0.000000] ACPI: Local APIC address 0xfee00000
My main concern is making sure
the machine is going to be O.K.
when in this state, or should I revert
to a stable kernel(2.6.28) until things get
worked out?
regards;
Justin P. Mattock
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..
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