On Mon, Jun 29, 2015 at 01:06:42PM +0100, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
It's totally legitimate, per the ACPI spec, for the firmware to set the
BGRT 'status' field to zero to indicate that the BGRT image isn't being
displayed, and we shouldn't be printing an
On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote:
Definitely not FW_BUG. The field is reserved *now*; it would be
legitimate for a new version of the BGRT spec to define one of those
bits for something else.
Which would mean that booting old kernels on new FW which defines those
On Mon, Jun 29, 2015 at 01:06:42PM +0100, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
It's totally legitimate, per the ACPI spec, for the firmware to set the
BGRT 'status' field to zero to indicate that the BGRT image isn't being
displayed, and we shouldn't be printing an
On Mon, Jun 29, 2015 at 03:13:05PM +0200, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 01:06:42PM +0100, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
It's totally legitimate, per the ACPI spec, for the firmware to set the
BGRT 'status' field to zero to indicate that
On Mon, Jun 29, 2015 at 10:17:40AM +0100, Matt Fleming wrote:
On Mon, 29 Jun, at 01:10:52AM, Tom Yan wrote:
My motherboard is ASUS H87-PRO which has UEFI BIOS. The kernel gives
the following error on every boot:
Ignoring BGRT: invalid status 0 (expected 1)
This happens when the Boot
On Mon, 29 Jun, at 01:10:52AM, Tom Yan wrote:
My motherboard is ASUS H87-PRO which has UEFI BIOS. The kernel gives
the following error on every boot:
Ignoring BGRT: invalid status 0 (expected 1)
This happens when the Boot Logo BIOS option is set to Auto (AND
using a PCI-E display card,
From: Matt Fleming matt.flem...@intel.com
It's totally legitimate, per the ACPI spec, for the firmware to set the
BGRT 'status' field to zero to indicate that the BGRT image isn't being
displayed, and we shouldn't be printing an error message in that case
because it's just noise for users. So
On Mon, Jun 29, 2015 at 04:17:24PM +0200, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote:
Definitely not FW_BUG. The field is reserved *now*; it would be
legitimate for a new version of the BGRT spec to define one of those
bits for something else.
On Mon, Jun 29, 2015 at 03:49:40PM +0100, Matt Fleming wrote:
On Mon, 29 Jun, at 04:17:24PM, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote:
Definitely not FW_BUG. The field is reserved *now*; it would be
legitimate for a new version of the BGRT spec
On Mon, Jun 29, 2015 at 03:49:40PM +0100, Matt Fleming wrote:
It still makes sense to have the error message because the kernel
literally does not know what the firmware is trying to achieve by
setting those bits.
But I agree with Josh that for the specific case of reserved bits,
FW_BUG is
On Mon, Jun 29, 2015 at 05:44:58PM +0200, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 03:49:40PM +0100, Matt Fleming wrote:
It still makes sense to have the error message because the kernel
literally does not know what the firmware is trying to achieve by
setting those bits.
But I
The memory error record structure includes as its first field a
bitmask of which subsequent fields are valid. The allows new fields
to be added to the structure while keeping compatibility with older
software that parses these records. This mechanism was used between
versions 2.2 and 2.3 to add
12 matches
Mail list logo
