On Thu, 2013-09-12 at 08:55 +0100, Matt Fleming wrote:
> On Tue, 10 Sep, at 10:43:27AM, Darren Hart wrote:
> > Josh OK'd this, but as far as I can tell, it hasn't made it upstream
> > yet. Matt was there an alternate fixed pushed?
>
> Nope, this one slipped through the cracks. Thanks for following
On Tue, 10 Sep, at 10:43:27AM, Darren Hart wrote:
> Josh OK'd this, but as far as I can tell, it hasn't made it upstream
> yet. Matt was there an alternate fixed pushed?
Nope, this one slipped through the cracks. Thanks for following up!
Here's the patch I just applied on the 'urgent' branch.
--
On Fri, 2013-04-19 at 08:50 +0100, Matt Fleming wrote:
> On 04/19/2013 01:18 AM, Darren Hart wrote:
> > On 04/18/2013 09:19 AM, Matt Fleming wrote:
> >>
> >> Could you give it a spin on your MinnowBoard?
> >
> > I've removed the patch I reference above and applied your patch to my
> > 3.8.4 Minnow
On Fri, Apr 19, 2013 at 08:50:14AM +0100, Matt Fleming wrote:
> On 04/19/2013 01:18 AM, Darren Hart wrote:
> > On 04/18/2013 09:19 AM, Matt Fleming wrote:
> >>
> >> Could you give it a spin on your MinnowBoard?
> >
> > I've removed the patch I reference above and applied your patch to my
> > 3.8.4
On 19/04/13 06:58, Greg KH wrote:
This patch gives the option to switch off that behavior - if your BIOS
has neither BGRT - nor bugs that require mapping of EFI boot code/data
No, never add new boot options, no users, or distros, know to set them.
Isn't there some way we can dynamically determi
On 04/19/2013 01:18 AM, Darren Hart wrote:
> On 04/18/2013 09:19 AM, Matt Fleming wrote:
>>
>> Could you give it a spin on your MinnowBoard?
>
> I've removed the patch I reference above and applied your patch to my
> 3.8.4 MinnowBoard dev tree. It panics with:
D'oh. OK, at this point I'm inclined
Nope, just a vehicle for experiments.
Greg KH wrote:
>On Thu, Apr 18, 2013 at 11:00:27PM -0700, H. Peter Anvin wrote:
>> The only real use for command line options is to be able to get users
>> to test something during troubleshooting.
>
>Ok, but the option shouldn't be used to "solve" the probl
On Thu, Apr 18, 2013 at 11:00:27PM -0700, H. Peter Anvin wrote:
> The only real use for command line options is to be able to get users
> to test something during troubleshooting.
Ok, but the option shouldn't be used to "solve" the problem.
greg k-h
--
To unsubscribe from this list: send the line
The only real use for command line options is to be able to get users to test
something during troubleshooting.
Greg KH wrote:
>On Wed, Apr 17, 2013 at 11:05:41PM +0100, Bryan O'Donoghue wrote:
>> Some EFI BIOS stores BGRT data in the wrong place and some EFI based
>> BIOS also requires mapping
On Wed, Apr 17, 2013 at 11:05:41PM +0100, Bryan O'Donoghue wrote:
> Some EFI BIOS stores BGRT data in the wrong place and some EFI based
> BIOS also requires mapping of boot code/data when doing
> efi_enter_virtual_mode.
>
> Current code in efi_enter_virtual_mode maps both EFI_RUNTIME_MEMORY and
>
On 04/18/2013 09:19 AM, Matt Fleming wrote:
> On 18/04/13 15:51, Darren Hart wrote:
>> I don't believe I have seen a 32-bit EFI system with a BGRT, but then
>> again, I had to look it up today! That said, I suspect the MinnowBoard
>> would benefit from such a thing, so we should have an example of
On 04/18/2013 04:01 PM, Josh Triplett wrote:
>
> I'd much rather see the code do the right thing automatically, rather
> than requiring an "unbreak me" command-line parameter.
>
> But in any case, since BGRT is a "make my system look prettier" feature
> rather than core functionality, giving up o
>
> "UEI" is Celtic for "We missed DOS so we burned it into your ROMS"
>
> I love it "maith an fear"
>
>> There are currently only two situations where we need to map EFI Boot
>> Service regions,
>>
>>1. To workaround the firmware bug described in 916f676f8
>>2. To access the ACPI BGRT i
On Thu, Apr 18, 2013 at 11:07:06PM +0100, Bryan O'Donoghue wrote:
>
> > UEFI stands for "Unified Extensible Firmware Interface", where
> > "Firmware"
> > is an ancient African word meaning "Why do something right when you can
> > do it so wrong that children will weep and brave adults
UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
is an ancient African word meaning "Why do something right when you can
do it so wrong that children will weep and brave adults will cower before
you", and "UEI" is Celtic for "We missed DOS so we burne
On 04/18/2013 01:17 PM, Darren Hart wrote:
>
> Ah, well then I've misunderstood the nature of the problem a bit. Will
> have to spend some time understanding this better.
>
Way, way too many people misunderstand HIGHMEM.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe
On 04/18/2013 01:13 PM, H. Peter Anvin wrote:
> On 04/18/2013 01:11 PM, Darren Hart wrote:
>>>
>>> I would expect that if there are any 32-bit UEFI systems that ship with
>>> BGRT support (and Darren makes it sound like that's a possibility),
>>> there's a realistic chance of the BGRT ending up all
On 04/18/2013 01:11 PM, Darren Hart wrote:
>>
>> I would expect that if there are any 32-bit UEFI systems that ship with
>> BGRT support (and Darren makes it sound like that's a possibility),
>> there's a realistic chance of the BGRT ending up allocated above the
>> highmem barrier.
>
> I can cert
On 04/18/2013 12:58 PM, Matthew Garrett wrote:
> On Thu, 2013-04-18 at 20:55 +0100, Matt Fleming wrote:
>
>> If there are machines out there that would require us to write support,
>> it's probably worth doing now instead of punting. But it sounds like
>> there aren't any.
>
> I would expect that
On Thu, 2013-04-18 at 20:55 +0100, Matt Fleming wrote:
> If there are machines out there that would require us to write support,
> it's probably worth doing now instead of punting. But it sounds like
> there aren't any.
I would expect that if there are any 32-bit UEFI systems that ship with
BGRT
On 04/18/2013 12:55 PM, Matt Fleming wrote:
> On 04/18/2013 05:44 PM, Josh Triplett wrote:
The machine I developed the BGRT changes on kept the image below the 4G
mark, inside one of the memory regions reclaimable via
ExitBootServices().
>>>
>>> Well, highmem is >= ~896M. Do you hav
On 04/18/2013 05:44 PM, Josh Triplett wrote:
>>> The machine I developed the BGRT changes on kept the image below the 4G
>>> mark, inside one of the memory regions reclaimable via
>>> ExitBootServices().
>>
>> Well, highmem is >= ~896M. Do you have a machine with BGRT over the
>> highmem mark?
>
On Thu, Apr 18, 2013 at 09:38:04AM -0700, H. Peter Anvin wrote:
> On 04/18/2013 09:33 AM, Josh Triplett wrote:
> > On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
> >>> No, no - we *don't* have a BGRT object at all.
> >>>
> >>> We have a completely clean memory map - but the BGRT code
On 04/18/2013 09:33 AM, Josh Triplett wrote:
> On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
>>> No, no - we *don't* have a BGRT object at all.
>>>
>>> We have a completely clean memory map - but the BGRT code is causing the
>>> is_ram() failure.
>>
>> You assume that mapping of t
On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
> > No, no - we *don't* have a BGRT object at all.
> >
> > We have a completely clean memory map - but the BGRT code is causing the
> > is_ram() failure.
>
> You assume that mapping of the Boot Services regions is done purely for
> th
On 18/04/13 15:51, Darren Hart wrote:
> I don't believe I have seen a 32-bit EFI system with a BGRT, but then
> again, I had to look it up today! That said, I suspect the MinnowBoard
> would benefit from such a thing, so we should have an example of it
> there in the near future.
That's fine and
On Thu, Apr 18, 2013 at 03:01:12PM +, Matthew Garrett wrote:
> On Thu, 2013-04-18 at 09:40 -0400, Josh Boyer wrote:
>
> > BGRT is a new addition in ACPI 5.0, right? Hopefully with it being
> > relatively recent, and new 32-bit firmware being somewhat rare, it won't
> > be a problem.
>
> New
On Thu, 2013-04-18 at 09:40 -0400, Josh Boyer wrote:
> BGRT is a new addition in ACPI 5.0, right? Hopefully with it being
> relatively recent, and new 32-bit firmware being somewhat rare, it won't
> be a problem.
New 32-bit UEFI firmware is fairly common. Thanks, Intel.
--
Matthew Garrett | mj
On 04/18/2013 04:00 AM, Matt Fleming wrote:
> On 17/04/13 23:00, Bryan O'Donoghue wrote:
>> In my mind the only memory that is relevant to efi_enter_virtual_mode is
>> memory that the BIOS has marked as EFI_RUNTIME_SERVICE
>>
>> md->attribute & 0x8000_
>>
>> I couldn't quite understand
On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
> On 17/04/13 23:00, Bryan O'Donoghue wrote:
> > In my mind the only memory that is relevant to efi_enter_virtual_mode is
> > memory that the BIOS has marked as EFI_RUNTIME_SERVICE
> >
> > md->attribute & 0x8000_
> >
> > I
On 17/04/13 23:00, Bryan O'Donoghue wrote:
> In my mind the only memory that is relevant to efi_enter_virtual_mode is
> memory that the BIOS has marked as EFI_RUNTIME_SERVICE
>
> md->attribute & 0x8000_
>
> I couldn't quite understand why the code in
>
> arch/x86/platform/efi/efi.c:e
Some EFI BIOS stores BGRT data in the wrong place and some EFI based
BIOS also requires mapping of boot code/data when doing
efi_enter_virtual_mode.
Current code in efi_enter_virtual_mode maps both EFI_RUNTIME_MEMORY and
BIOS boot code/data.
This patch gives the option to switch off that behavior
On 17/04/13 15:06, Matt Fleming wrote:
(Cc'ing some more folks)
On 16/04/13 16:58, Bryan O'Donoghue wrote:
This warning is caused by efi_enter_virtual_mode mapping memory marked
as !EFI_RUNTIME_MEMORY. The reason this memory is being mapped is to
work around buggy code that stores an ACPI objec
(Cc'ing some more folks)
On 16/04/13 16:58, Bryan O'Donoghue wrote:
> This warning is caused by efi_enter_virtual_mode mapping memory marked
> as !EFI_RUNTIME_MEMORY. The reason this memory is being mapped is to
> work around buggy code that stores an ACPI object called the Boot
> Graphics Resourc
This warning is caused by efi_enter_virtual_mode mapping memory marked
as !EFI_RUNTIME_MEMORY. The reason this memory is being mapped is to
work around buggy code that stores an ACPI object called the Boot
Graphics Resource Table - BGRT in memory of type EfiBootServices*.
[ cut here ]-
35 matches
Mail list logo
