On Fri, Jan 31, 2014 at 03:23:18PM +0100, Borislav Petkov wrote:
And now my question:
How can I reliably find out which region contains that
uv_systab.function call?
I need it so that I can map it in the EFI page table and you can
continue to call that function and you can get back to
On Wed, Feb 05, 2014 at 03:45:36PM -0600, Alex Thorlton wrote:
While working on an answer to this question, I ran across another issue
on some newer hardware, that looks like it's definitely related to this
problem, and might be the root cause.
When booting on a UV2 we die in
On Thu, 30 Jan, at 04:19:50PM, Alex Thorlton wrote:
Re-adding lkml.
Also add linux-efi.
The quick answer is I think it is a virtual address, because
it does not work in physical mode. If you ever see virtefi
on the RHEL bootline it is because RH switched the default
to physical mode,
On Fri, Jan 31, 2014 at 08:04:28AM +, Matt Fleming wrote:
On Thu, 30 Jan, at 04:19:50PM, Alex Thorlton wrote:
Re-adding lkml.
Also add linux-efi.
The quick answer is I think it is a virtual address, because
it does not work in physical mode. If you ever see virtefi
on the RHEL
On Fri, Jan 31, 2014 at 11:07:22AM +0100, Borislav Petkov wrote:
On Thu, Jan 30, 2014 at 02:23:46PM -0800, H. Peter Anvin wrote:
On 01/30/2014 02:19 PM, Alex Thorlton wrote:
The quick answer is I think it is a virtual address, because it does
not work in physical mode. If you ever see
On Fri, Jan 31, 2014 at 08:02:21AM -0600, Russ Anderson wrote:
I'm not sure what you are asking for. We had a reliable
way to boot before the recent patch broke it. (commit
d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c)
So we should stop any further development just because your machines did
boot
On Fri, Jan 31, 2014 at 03:23:18PM +0100, Borislav Petkov wrote:
So we should stop any further development just because your machines did
boot nicely before that. What about the other machines and kexec we're
fixing with the work above? Jeez...
Alternatively, we can force the old memmap method