Severity of ACPI Error Message from _SRS

[Colin Ian King]

On 25/01/13 10:29, Alex Hung wrote:
> On 01/25/2013 05:37 PM, Colin Ian King wrote:
>> On 25/01/13 09:22, Alex Hung wrote:
>>> Hi,
>>>
>>> It is found that kernel generates ACPI error messages on AMI's BIOS's
>>> implementation when kernel executes _SRS messages, as the launchpad bug
>>> below
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1076979
>>>
>>> Apparently kernel follows ACPI specification but BIOS did not handle it
>>> correctly; however, the error messages has not caused function failure
>>> so far.
>>>
>>> Some facts:
>>> 1. It is only seen on AMI's BIOS
>>> 2. S3, S4, and reboot failures are not related to this errors so far.
>>> 3. It only happens on super I/O devices, i.e. LPT (for printer port) and
>>> UART (for serial port) that reside in LPC bridge.
>>> 4. _SRS method is optional.
>>> 5. BIOS usually configures LPT and UART, if presents, during *POST*
>>> time.
>>> 6. We haven't seen LPT or UART failures even when the ACPI errors are
>>> presents.
>>>
>>> For longer term, it is needed to feedback BIOS vendor to have this
>>> fixed.
>>>
>>> For now, the failures are marked as CRITICAL. It is suggested that we
>>> may lower it to HIGH or MEDIUM. I personally think it is not a bad idea
>>> for the reasons above.
>>>
>>> Any thoughts?
>>>
>>> Cheers,
>>> Alex Hung
>>>
>>>
>> The reason that this is marked CRITICAL is that the firmware is given a
>> buffer that is too short and we have an attempt to access memory outside
>> this buffer.  fwts doesn't care about which control this happens to, any
>> access outside an buffer is really not good, so it is marked as so.
>>
>> I consider this as bad as a buffer overflow in C - although in this case
>> the interpreter is able to catch so we don't actually crash and burn.
>> The issue is that the code is trying to set something which can't be set
>> - and so the interpreter can't do it and the end result is something
>> that isn't working correctly.  fwts has to make a best guess judgement
>> and flags this up as critical for a few reasons:
>>
>> 1. The code is obviously badly wrong
> Totally agree. We are highlighting to BIOS vendor and hope they are
> going to fix it this time.
>> 2. An attempt to write to memory outside a given range is always a bad
>> bug
>> 3. The end result is that the action is aborted, so who knows what the
>> end result will be, the outcome is not predictable.
>>
>> Hence why it is flagged as critical, so that somebody will look at it
>> and see why it is failing so miserably ;-)
>>
> This is a good point. I think we still need to have this fixed in BIOS
> code. Some critical error messages won't hurt but it will keep us reminded.
>
> Thanks Colin.
>
> Cheers,
> Alex Hung
>
>> Colin
>>
>
>
Further to this, I'm sending a patch to catch this particular issue.

Colin