* FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) @ 2009-01-10 5:59 Justin P. Mattock 2009-01-10 8:25 ` Robert Hancock 0 siblings, 1 reply; 5+ messages in thread From: Justin P. Mattock @ 2009-01-10 5:59 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) 2009-01-10 5:59 FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) Justin P. Mattock @ 2009-01-10 8:25 ` Robert Hancock 2009-01-10 16:23 ` Justin P. Mattock 0 siblings, 1 reply; 5+ messages in thread From: Robert Hancock @ 2009-01-10 8:25 UTC (permalink / raw) To: Justin P. Mattock; +Cc: linux-kernel 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) 2009-01-10 8:25 ` Robert Hancock @ 2009-01-10 16:23 ` Justin P. Mattock 2009-01-11 0:02 ` Robert Hancock 0 siblings, 1 reply; 5+ messages in thread From: Justin P. Mattock @ 2009-01-10 16:23 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) 2009-01-10 16:23 ` Justin P. Mattock @ 2009-01-11 0:02 ` Robert Hancock 2009-01-11 0:23 ` Justin P. Mattock 0 siblings, 1 reply; 5+ messages in thread From: Robert Hancock @ 2009-01-11 0:02 UTC (permalink / raw) To: Justin P. Mattock; +Cc: linux-kernel 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.. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) 2009-01-11 0:02 ` Robert Hancock @ 2009-01-11 0:23 ` Justin P. Mattock 0 siblings, 0 replies; 5+ messages in thread From: Justin P. Mattock @ 2009-01-11 0:23 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-01-11 0:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-10 5:59 FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) Justin P. Mattock 2009-01-10 8:25 ` Robert Hancock 2009-01-10 16:23 ` Justin P. Mattock 2009-01-11 0:02 ` Robert Hancock 2009-01-11 0:23 ` Justin P. Mattock
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox