810dfba 100644
> > --- a/arch/x86/include/asm/uv/bios.h
> > +++ b/arch/x86/include/asm/uv/bios.h
> > @@ -5,6 +5,7 @@
> > /*
> > * UV BIOS layer definitions.
> > *
> > + * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
> > * Co
changed, 746 insertions(+), 237 deletions(-)
> rename drivers/firmware/efi/{arm-init.c => efi-init.c} (99%)
> create mode 100644 drivers/firmware/efi/mokvar-table.c
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
t; drivers/firmware/efi/cper.c | 18 --
> include/linux/cper.h| 24 ++--
> 3 files changed, 53 insertions(+), 6 deletions(-)
>
> --
> 2.26.2
>
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
ith quick testing on a 32 socket, 1536 CPU, 12 TB memory
Cascade Lake system and a 8 socket, 144 CPU, 3 TB memory
Cooper Lake system without any obvious regression.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
tch
to remove old SGI UV1 code. Dimitri Sivanich is working on a
sgi_rtc cleanup patch. We are looking at additional cleanup
that should have been done previously.
Steve Wahl will be involved on an ongoing basis, so
you will see more from us.
Thanks.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
if (cpumask)
> > - smp_call_function_many(cpumask, flush_tlb_func_remote,
> > - (void *)info, 1);
> > - return;
> > - }
> > -
> > /*
> > * If no page tables were freed, we can skip sending IPIs to
> > * CPUs in lazy TLB mode. They will flush the CPU themselves
> > --
> > 2.17.1
> >
> >
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
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 serialised whic
> ../../../devices/system/edac/mc/mc0/csrow0
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm0 ->
> ../../../devices/system/edac/mc/mc0/dimm0
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm3 ->
> ../../../devices/system/edac/mc/mc0/dimm3
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm6
> ../../../devices/system/edac/mc/mc0/csrow0
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm0 ->
> ../../../devices/system/edac/mc/mc0/dimm0
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm3 ->
> ../../../devices/system/edac/mc/mc0/dimm3
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm6
sockets?
> Normally, the number "1" in the above string "Skylake Socekt#1 IMC#1"
> should be 7 (that was 15/2), but it was 1 here.
Yes, that is from a 32 socket system.
Thanks.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
sockets?
> Normally, the number "1" in the above string "Skylake Socekt#1 IMC#1"
> should be 7 (that was 15/2), but it was 1 here.
Yes, that is from a 32 socket system.
Thanks.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
latforms,
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)
latforms,
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)
t; >>> - mmr_value = 0;
> >>> - entry = (struct uv_IO_APIC_route_entry *)_value;
> >>> -
> >>> - entry->vector = cfg->vector;
> >>> - entry->delivery_mode= apic->irq_delivery_mode;
> >>> - entry->des
the FAQ at http://www.tux.org/lkml/
--
Russ Anderson, Kernel and Performance Software Team Manager
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
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
On Tue, Mar 04, 2014 at 05:02:17PM +0100, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
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 r...@sgi.com
Signed
On Fri, Feb 21, 2014 at 12:13:13AM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 17:59 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 11:09:42PM +, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
> > > >
>
:-)
I don't want to join the fight, either.
I have not looked at your code changes but the description
looks like the right direction.
> > From: linux-acpi-ow...@vger.kernel.org
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Russ Anderson
> > Sent: Friday, February 2
the fight, either.
I have not looked at your code changes but the description
looks like the right direction.
From: linux-acpi-ow...@vger.kernel.org
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Russ Anderson
Sent: Friday, February 21, 2014 7:59 AM
On Thu, Feb 20, 2014 at 11:09
On Fri, Feb 21, 2014 at 12:13:13AM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 17:59 -0600, Russ Anderson wrote:
On Thu, Feb 20, 2014 at 11:09:42PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
The ACPI spec requires IPMI functionality
On Thu, Feb 20, 2014 at 11:09:42PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 10:26:45PM +, Matthew Garrett wrote:
>
> > > Because I'm trying to ensure that the default behaviour of the ker
uot;?
> Set the default to Y in order to encourage distributions and
> users to configure kernels to avoid awkward surprises.
What are the "awkward surprises"?
Thanks,
--
Russ Anderson, Kernel and Performance Software Team Manager
SGI - Silicon Graphics Inc r...@sgi.c
On Thu, Feb 20, 2014 at 10:26:45PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 16:06 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 09:39:23PM +, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 15:28 -0600, Russ Anderson wrote:
> > >
>
On Thu, Feb 20, 2014 at 09:39:23PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 15:28 -0600, Russ Anderson wrote:
>
> > For some customers _any_ amount is significant, especially
> > on large clustered systems where the amount is multiplied
> > by tens or hundre
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
>
> > There are any number of reasons why a BMC may not respond.
> > BMCs are notorious for being flakey, with different types
> > of BMCs that ma
On Thu, Feb 20, 2014 at 09:00:48PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:59 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
> > >
>
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
>
> > This is also a problem for systems with functional BMCs. Our
> > large cluster systems do all IPMI traffic (monitoring) through
> > a system c
On Thu, Feb 20, 2014 at 08:16:22PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:14 -0600, Russ Anderson wrote:
>
> > The distro that added this change created all sorts of support
> > problems. Problems include kipmi0 spinning at 100% of cpu
> > (creating a p
for System Interfaces (KCS, SMIC, BT).
>Currently, only KCS and SMIC are supported. If
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordo
driver.
The distro that added this change created all sorts of support
problems. Problems include kipmi0 spinning at 100% of cpu
(creating a performance hit) and long boot delays (as the
kernel tries to talk to a BMC that will never respond).
It has been a big mess.
Nacked-by: Russ Anderson r
On Thu, Feb 20, 2014 at 08:16:22PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 14:14 -0600, Russ Anderson wrote:
The distro that added this change created all sorts of support
problems. Problems include kipmi0 spinning at 100% of cpu
(creating a performance hit) and long boot
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
This is also a problem for systems with functional BMCs. Our
large cluster systems do all IPMI traffic (monitoring) through
a system controller back door. We do
On Thu, Feb 20, 2014 at 09:00:48PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 14:59 -0600, Russ Anderson wrote:
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
This is also a problem for systems
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
There are any number of reasons why a BMC may not respond.
BMCs are notorious for being flakey, with different types
of BMCs that may or may not be reliable. You do
On Thu, Feb 20, 2014 at 09:39:23PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 15:28 -0600, Russ Anderson wrote:
For some customers _any_ amount is significant, especially
on large clustered systems where the amount is multiplied
by tens or hundreds of thousands of nodes.
You
On Thu, Feb 20, 2014 at 10:26:45PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 16:06 -0600, Russ Anderson wrote:
On Thu, Feb 20, 2014 at 09:39:23PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 15:28 -0600, Russ Anderson wrote:
For some customers _any_ amount
in order to encourage distributions and
users to configure kernels to avoid awkward surprises.
What are the awkward surprises?
Thanks,
--
Russ Anderson, Kernel and Performance Software Team Manager
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line
On Thu, Feb 20, 2014 at 11:09:42PM +, Matthew Garrett wrote:
On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
On Thu, Feb 20, 2014 at 10:26:45PM +, Matthew Garrett wrote:
Because I'm trying to ensure that the default behaviour of the kernel is
to *work*. Defaulting
hysical/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 recent patch broke it. (c
Is 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 Ma
. 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
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line
to do that during boot?
I'm not sure what you are asking for. We had a reliable way to
boot before the recent patch broke it. (commit
d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c)
--
Russ Anderson, Kernel and Performance Software Team Manager
SGI - Silicon Graphics Inc r...@sgi.com
hardware with
> more than 4096 CPUs?
Yes. We have a system in the lab with 254 12-core IVB sockets for
a total of 3048 cores. With HT is it 6096 cpus.
> If so, I can actually make a bump to the MAXSMP count a separate patch.
>
> josh
--
Russ Anderson, OS RAS/Partitioning Project Lead
a separate patch.
josh
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
CPUS=4096 wasn't working very well and you had to select MAXSMP
> > deliberately and keep all the pieces.
> >
> > But today it's all pretty robust so I see no reason why not to allow up to
> > 4096 CPUs.
>
> Adding Russ from SGI as they are one of the consumers of a large C
.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Commit-ID: dd3c9c4b603c664fedc12facf180db0f1794aafe
Gitweb: http://git.kernel.org/tip/dd3c9c4b603c664fedc12facf180db0f1794aafe
Author: Russ Anderson
AuthorDate: Mon, 14 Oct 2013 11:17:34 -0500
Committer: Ingo Molnar
CommitDate: Tue, 15 Oct 2013 08:44:46 +0200
x86: Update UV3 hub
Commit-ID: dd3c9c4b603c664fedc12facf180db0f1794aafe
Gitweb: http://git.kernel.org/tip/dd3c9c4b603c664fedc12facf180db0f1794aafe
Author: Russ Anderson r...@sgi.com
AuthorDate: Mon, 14 Oct 2013 11:17:34 -0500
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 15 Oct 2013 08:44:46
The UV3 hub revision ID is different than expected. The first
revision was supposed to start at 1 but instead will start at 0.
Signed-off-by: Russ Anderson
---
arch/x86/kernel/apic/x2apic_uv_x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/x86/kernel/apic
The UV3 hub revision ID is different than expected. The first
revision was supposed to start at 1 but instead will start at 0.
Signed-off-by: Russ Anderson r...@sgi.com
---
arch/x86/kernel/apic/x2apic_uv_x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/x86/kernel
On Mon, Aug 26, 2013 at 02:49:59PM -0700, Andrew Morton wrote:
> On Fri, 23 Aug 2013 11:23:17 -0500 Russ Anderson wrote:
>
> > "cat /sys/devices/system/memory/memory*/removable" crashed the system.
> >
> > The problem is that show_mem_re
On Mon, Aug 26, 2013 at 02:49:59PM -0700, Andrew Morton wrote:
On Fri, 23 Aug 2013 11:23:17 -0500 Russ Anderson r...@sgi.com wrote:
cat /sys/devices/system/memory/memory*/removable crashed the system.
The problem is that show_mem_removable() is passing a
bad pfn
-rw-r--r-- 1 root root 21330 Aug 23 21:23 ssdt.dat
-rw-r--r-- 1 root root 92 Aug 23 21:23 uefi1.dat
-rw-r--r-- 1 root root 298 Aug 23 21:23 uefi.dat
-rw-r--r-- 1 root root 124 Aug 23 21:23 xsdt.dat
---
--
Russ Anderson, OS RAS/Partit
0 0105C (v01 SGI2 UVX 0002 MSFT 0001)
ACPI: SPCR 7e6c2000 00050 (v01 )
ACPI: DMAR 7d6d3000 0013C (v01 INTEL TIANO0001 MSFT 0113)
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r.
.
Signed-off-by: Russ Anderson
The failing output:
---
harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
0
1
1
1
1
1
1
1
1
1
1
1
1
1
[ 372.78] BUG: unable to handle kernel paging request at ea00c320
[ 3
i))
> continue;
Yes, I will make that change and resubmit the patch.
Thanks.
> Thanks,
> Yasuaki Ishimatsu
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line
that change and resubmit the patch.
Thanks.
Thanks,
Yasuaki Ishimatsu
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
, PAGES_PER_SECTION);
}
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
0001 MSFT 0113)
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
root 124 Aug 23 21:23 xsdt.dat
---
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Thu, Aug 22, 2013 at 09:10:45PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Aug 22, 2013 at 09:38:38PM -0500, Russ Anderson wrote:
> > "cat /sys/devices/system/memory/memory*/removable" crashed the system.
>
> On what kernels? linux-next or Linus's tree, or 3.10.y?
I suspect other usages of sections_per_block will also
need to be fixed.
Signed-off-by: Russ Anderson
The failing output:
---
harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
0
1
1
1
1
1
1
1
1
1
1
1
1
1
[ 372.78] BUG:
On Thu, Aug 22, 2013 at 09:10:45PM -0700, Greg Kroah-Hartman wrote:
On Thu, Aug 22, 2013 at 09:38:38PM -0500, Russ Anderson wrote:
cat /sys/devices/system/memory/memory*/removable crashed the system.
On what kernels? linux-next or Linus's tree, or 3.10.y?
Linus 3.11-rc6
--
Russ Anderson
of sections_per_block will also
need to be fixed.
Signed-off-by: Russ Anderson r...@sgi.com
The failing output:
---
harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
0
1
1
1
1
1
1
1
1
1
1
1
1
1
[ 372.78] BUG: unable
2.23%)
UV2: 255 nodes 16TB:1141.02 1138.12 -2.90 (0.25%)
UV2: 64 nodes 2TB: 128.15 126.53 -1.62 (1.26%)
UV2: 32 nodes 2TB: 121.87 121.07 -0.80 (0.66%)
Time in seconds.
Acked-by: Russ Anderson
> > ...
>
On Fri, Aug 16, 2013 at 12:15:21PM -0700, Yinghai Lu wrote:
> On Fri, Aug 16, 2013 at 12:01 PM, Russ Anderson wrote:
> > On Thu, Aug 15, 2013 at 01:43:48PM -0700, Andrew Morton wrote:
> >> On Wed, 14 Aug 2013 22:46:29 -0700 Yinghai Lu wrote:
> >>
> >>
On Fri, Aug 16, 2013 at 12:15:21PM -0700, Yinghai Lu wrote:
On Fri, Aug 16, 2013 at 12:01 PM, Russ Anderson r...@sgi.com wrote:
On Thu, Aug 15, 2013 at 01:43:48PM -0700, Andrew Morton wrote:
On Wed, 14 Aug 2013 22:46:29 -0700 Yinghai Lu ying...@kernel.org wrote:
Current early_pfn_to_nid
-2.90 (0.25%)
UV2: 64 nodes 2TB: 128.15 126.53 -1.62 (1.26%)
UV2: 32 nodes 2TB: 121.87 121.07 -0.80 (0.66%)
Time in seconds.
Acked-by: Russ Anderson r...@sgi.com
...
--- linux-2.6.orig/include/linux/memblock.h
t;
> > Looks nice. I wonder how much difference it makes.
>
> Russ said he would test on his 256 nodes system, but looks he never
> got chance.
I reserved time tonight on a couple big systems to measure
the performance difference.
Thanks,
--
Russ Anderson, OS RAS/Partitioning
would test on his 256 nodes system, but looks he never
got chance.
I reserved time tonight on a couple big systems to measure
the performance difference.
Thanks,
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list
t...
> + */
> + efi.set_variable(efi_dummy_name, _DUMMY_GUID,
> + EFI_VARIABLE_NON_VOLATILE |
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARI
+ */
+ if (remaining_size - size EFI_MIN_RESERVE)
+ return EFI_OUT_OF_RESOURCES;
+ }
return EFI_SUCCESS;
}
--
1.8.1.4
--
Matt Fleming, Intel Open Source Technology Center
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r
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
* that we delete it...
> + */
> + efi.set_variable(efi_dummy_name, _DUMMY_GUID,
> + EFI_VARIABLE_NON_VOLATILE |
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +
+ */
+ if (remaining_size - size EFI_MIN_RESERVE)
+ return EFI_OUT_OF_RESOURCES;
+ }
return EFI_SUCCESS;
}
--
1.8.1.4
--
Matt Fleming, Intel Open Source Technology Center
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI
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 that's what it takes
* that we delete it...
> + */
> + efi.set_variable(efi_name, , attributes, 0,
> + dummy);
> + }
>
> - if (!storage_size || size > remaining_size ||
> - (max_size &
://www.tux.org/lkml/
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
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 r...@sgi.com
means the previous patch(es) that caused the bricking should
get pulled, too.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
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
that use EFI stubs
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
systems crash during
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:
> > >
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
> > patch is
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 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()
--
see the surrounding code, see for example this in efi_main
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
patch is consistent with the UEFI spec
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
patch is consistent with the UEFI spec and avoids
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:
That's a great idea. This patch moves
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 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 the failure? I suspect Fedora19/grub2
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,
range
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
your firmware because we're at runtime
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:
> > > >
1 - 100 of 159 matches
Mail list logo
