On Thu, 23 May, at 05:23:21PM, Russ Anderson wrote:
Interesting data point. The failure is on a rhel7/grub2 root.
The identical kernel on a rhel6/grub root boots. So maybe
grub2 brings out the failure? I suspect Fedora19/grub2 on
EFI should hit the problem (for someone looking to reproduce
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
What appears to be happening is that your the EFI runtime services
code is calling into the EFI boot services code, which is definitely
a bug in your firmware because we're at runtime, but we've seen
other machines that do similar
Russ,
Can we open a bug for the BIOS folks and see if we can get this addressed?
Robin
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
efi: mem127: type=4, attr=0xf,
range=[0x6bb22000-0x7ca9c000) (271MB)
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
efi: mem127: type=4, attr=0xf,
range=[0x6bb22000-0x7ca9c000) (271MB)
EFI_BOOT_SERVICES_CODE
efi: mem133: type=5, attr=0x800f,
On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote:
One other data point is if the query_variable_info call is hacked to
remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS)
the efi_call_phys4() call fails with EFI_INVALID_PARAMETER and
the system boots. Of course
On Fri, May 24, 2013 at 08:11:01PM +, Matthew Garrett wrote:
On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote:
One other data point is if the query_variable_info call is hacked to
remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS)
the efi_call_phys4()
On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
Russ,
Can we open a bug for the BIOS folks and see if we can get this addressed?
I already talked with them. It is not in an area that we
normally change,
