On Tue, Feb 11, 2014 at 04:19:03PM -0600, Alex Thorlton wrote:
> Have there been any developments on this since last week, Boris? Just
> trying to make sure that we stay in the loop on this issue.
>
> Let me know if there's anything else we can do from our end to help
> expedite the process. I'm al
On Thu, Feb 06, 2014 at 12:15:40AM +0100, Borislav Petkov wrote:
> 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
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 efi_enter_v
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
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 meth
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 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 yo
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 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 "virtefi" on the RHEL
> > bootline it is because RH switched the
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 01/30/2014 02:19 PM, Alex Thorlton wrote:
>
> The quick answer is I think it is a virtual address, because
>
>
>
Re-adding lkml.
Here's what we've got as far as your questions go (snipped from an
e-mail from Russ):
> * what kind of a pointer is that, physical address, or?
The quick answer is I think it is a virtual address, because
On Thu, Jan 23, 2014 at 04:11:08PM -0600, Alex Thorlton wrote:
> We've been hitting the following bug in the latest kernel, during boot:
Can you merge
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git#next
into your tree, enable CONFIG_EFI_PGT_DUMP, apply the debugging patch
below,
We've been hitting the following bug in the latest kernel, during boot:
kernel BUG at arch/x86/mm/init_64.c:351!
invalid opcode: [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-medusa-04156-g90804ed-dirty
#750
Hardware name: Intel Corp. Stoutland Platform, BIOS 2
14 matches
Mail list logo
