Messages in this thread | | | Date | Sat, 10 Jan 2009 16:23:38 -0800 | From | "Justin P. Mattock" <> | Subject | Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) |
| |
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
| |