Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)

[Justin P. Mattock]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/