requisites for that change.
>
> Also, if your colleagues reviewed your patches, now would be the time
> to ask them to give their Reviewed-by as well.
Reviewed-by: Russ Anderson
Thanks.
> --
> Ard.
>
>
>
> > ---
> >
> > Calls into UV BIOS were not being
platforms,
both old and new mapping, with new mapping being the default.
Thanks.
--
Russ Anderson, Hawks 2 Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com (r...@sgi.com)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" i
On Tue, Mar 04, 2014 at 05:02:17PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Getting this thing to work with the new mapping scheme would need more
> work.
Thanks Boris. Allows SGI UV to boot (without the extra bootline).
Acked-by: Russ Anderson
> Signed-o
's. Physical/virtual shouldn't matter all that much
> because we map the region *both* as a 1:1 map and in virtual space too.
>
> Can SGI please give us a reliable way to do that during boot?
I'm not sure what you are asking for. We had a reliable way to
boot before the recen
it a
> limitation of the firmware?
That was a non-upstream regression in the distro kernel. The
3.13 community kernel was boots fine. The current problem is a
regression introduced in this merge window which needs to be fixed.
--
Russ Anderson, Kernel and Performance Software Team Manager
dummy_size, dummy);
> +
> + if (status == EFI_SUCCESS) {
> + /*
> + * This should have failed, so if it didn't make sure
> + * that we delete it...
> + */
On Thu, Jun 06, 2013 at 04:00:39PM +0100, Matt Fleming wrote:
> On Thu, 06 Jun, at 09:48:46AM, Russ Anderson wrote:
> > This looks like it will try to allocate more than the remaining size.
> > Is that intended?
>
> Yes, the intention is to trigger garbage collection.
OK, if
BLE_RUNTIME_ACCESS,
> + dummy_size, dummy);
> +
> + if (status == EFI_SUCCESS) {
> + /*
> + * This should have failed, so if it didn't make sure
> + * that we delete
*/
> + efi.set_variable(efi_name, &guid, attributes, 0,
> + dummy);
> + }
>
> - if (!storage_size || size > remaining_size ||
> - (max_size && size > max_size))
> - r
On Sat, Jun 01, 2013 at 01:03:11AM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 05:57:31PM -0500, Russ Anderson wrote:
> > On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> > > If nvram becaomes full, some
&
On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 10:43:49AM -0500, Russ Anderson wrote:
>
> > When did writing EFI variables to nvram become necessary to boot on
> > UEFI? And if it is necessary, why is it that only linux boot loaders
In any case, Samsung clearly
> haven't fixed this problem on a pile of machines that have already
> shipped.
Which means the previous patch(es) that caused the bricking should
get pulled, too.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc
On Thu, May 30, 2013 at 10:32:09PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> > On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> > >
> &g
On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
> On Thu, 30 May 2013, Russ Anderson wrote:
>
> > > > That's a great idea. This patch moves the QueryVariableInfo()
> > > > call from bootime to runtime, in efi_late_init(). The attached
> > &
On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
>
> > That's a great idea. This patch moves the QueryVariableInfo()
> > call from bootime to runtime, in efi_late_init(). The attached
> > patc
On Thu, May 30, 2013 at 10:16:12AM +0800, joeyli wrote:
> 於 四，2013-05-30 於 00:53 +0200，Jiri Kosina 提到：
> > On Wed, 29 May 2013, Russ Anderson wrote:
> >
> > > > Yes, but this call is clearly happening way before ExitBootServices()
> > > > --
> >
On Thu, May 30, 2013 at 12:22:13AM +0200, Jiri Kosina wrote:
> On Wed, 29 May 2013, Russ Anderson 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
> >
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: t
On Fri, May 24, 2013 at 08:45:44AM +0100, Matt Fleming wrote:
> 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 th
On Mon, May 27, 2013 at 12:27:12PM +0800, joeyli wrote:
> Hi Dave,
>
> 於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
> > 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:
> > > > Ru
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_BOOTSERVI
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: t
lementation. That still makes it a kernel bug.
I'm still digging to better understand the root problem.
> 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: mem12
On Thu, May 23, 2013 at 12:58:01PM +0100, Matt Fleming wrote:
> On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> > [6.062157] EFI Variables Facility v0.08 2004-May-17
> > [6.067731] BUG: unable to handle kernel paging request at
> > 7ca95b10
On Thu, May 23, 2013 at 12:58:01PM +0100, Matt Fleming wrote:
> On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> > [6.062157] EFI Variables Facility v0.08 2004-May-17
> > [6.067731] BUG: unable to handle kernel paging request at
> > 7ca95b10
785] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
---
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line "unsubscri
26 matches
Mail list logo
