linux-kernel - Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Jan 2009 18:02:40 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	linux-kernel@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject:  Re: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN
   (4)

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..

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