[PATCH]IA64: assign a distinguishable label to uncached memory in

[PATCH]IA64: assign a distinguishable label to uncached memory in

[Jay Lan]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
is denoted as "System RAM" in /proc/iomem, while memory of attribute
(EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.

The kexec utility then includes uncached memory as part of vmcore. The
kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal
"cached" access may cause MCAs.

This patch would label memory with attribute of EFI_MEMORY_UC only as
"Uncached RAM" so that kexec would know not to include it in the vmcore.
I will submit a separate kexec-tools patch to the kexec list.

Signed-off-by: Jay Lan <jlan@sgi.com>



[-- Attachment #2: UC-mem --]
[-- Type: text/plain, Size: 647 bytes --]

---
 arch/ia64/kernel/efi.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: linux/arch/ia64/kernel/efi.c
===================================================================
--- linux.orig/arch/ia64/kernel/efi.c
+++ linux/arch/ia64/kernel/efi.c
@@ -1232,9 +1232,10 @@ efi_initialize_iomem_resources(struct re
 				if (md->attribute & EFI_MEMORY_WP) {
 					name = "System ROM";
 					flags |= IORESOURCE_READONLY;
-				} else {
-					name = "System RAM";
-				}
+				} else if (md->attribute == EFI_MEMORY_UC)
+						name = "Uncached RAM";
+					else
+						name = "System RAM";
 				break;
 
 			case EFI_ACPI_MEMORY_NVS:

Re: [PATCH]IA64: assign a distinguishable label to uncached memory

[Bernhard Walle]

* Jay Lan <jlan@sgi.com> [2008-09-11]: 

> -				} else {
> -					name = "System RAM";
> -				}
> +				} else if (md->attribute = EFI_MEMORY_UC)
> +						name = "Uncached RAM";
> +					else
> +						name = "System RAM";
                                ^^^^^^^^

Isn't that too much indent, i.e. shouldn't that be

--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1232,9 +1232,10 @@ efi_initialize_iomem_resources(struct re
                                if (md->attribute & EFI_MEMORY_WP) {
                                        name = "System ROM";
                                        flags |= IORESOURCE_READONLY;
-                               } else {
+                               } else if (md->attribute =
EFI_MEMORY_UC)
+                                       name = "Uncached RAM";
+                               else
                                        name = "System RAM";
-                               }
                                break;



Bernhard

Re: [PATCH]IA64: assign a distinguishable label to uncached memory

[Bernhard Walle]

* Bernhard Walle <bwalle@suse.de> [2008-09-12]: 

> Isn't that too much indent, i.e. shouldn't that be

Of course

--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1232,9 +1232,10 @@ efi_initialize_iomem_resources(struct re
                                if (md->attribute & EFI_MEMORY_WP) {
                                        name = "System ROM";
                                        flags |= IORESOURCE_READONLY;
-                               } else {
+                               } else if (md->attribute = EFI_MEMORY_UC)
+                                       name = "Uncached RAM";
+                               else
                                        name = "System RAM";
-                               }
                                break;
 
                        case EFI_ACPI_MEMORY_NVS:


My mailer decided to wrap the pasted text (which is my fault).


Bernhard

Re: [PATCH]IA64: assign a distinguishable label to uncached memory

[Jay Lan]

Bernhard Walle wrote:
> * Bernhard Walle <bwalle@suse.de> [2008-09-12]: 
> 
>> Isn't that too much indent, i.e. shouldn't that be
> 
> Of course

Yep! Thanks for correction.

jay

> 
> --- a/arch/ia64/kernel/efi.c
> +++ b/arch/ia64/kernel/efi.c
> @@ -1232,9 +1232,10 @@ efi_initialize_iomem_resources(struct re
>                                 if (md->attribute & EFI_MEMORY_WP) {
>                                         name = "System ROM";
>                                         flags |= IORESOURCE_READONLY;
> -                               } else {
> +                               } else if (md->attribute = EFI_MEMORY_UC)
> +                                       name = "Uncached RAM";
> +                               else
>                                         name = "System RAM";
> -                               }
>                                 break;
>  
>                         case EFI_ACPI_MEMORY_NVS:
> 
> 
> My mailer decided to wrap the pasted text (which is my fault).
> 
> 
> Bernhard
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH]IA64: assign a distinguishable label to uncached memory

[Simon Horman]

On Thu, Sep 11, 2008 at 04:00:08PM -0700, Jay Lan wrote:
> Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
> is denoted as "System RAM" in /proc/iomem, while memory of attribute
> (EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
> 
> The kexec utility then includes uncached memory as part of vmcore. The
> kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal
> "cached" access may cause MCAs.
> 
> This patch would label memory with attribute of EFI_MEMORY_UC only as
> "Uncached RAM" so that kexec would know not to include it in the vmcore.
> I will submit a separate kexec-tools patch to the kexec list.
> 
> Signed-off-by: Jay Lan <jlan@sgi.com>

Hi Jay,

I've taken a look on an RX2620, Tiger2 and Tiger4 and none of these
machines have EFI memory regions that are covered by this new check. That
is, any regions with the EFI_MEMORY_UC bit set in the attribute either also
have other attibute bits set, or are of a type not covered by this.

I strongly suspect that this is not a problem, but I wanted to bring it to
your attention anyway. I can provide more detailed EFI information from any
or all of these machines if you need it.

With regards to the kexec-tools portion of this patch, it looks fine to me
and I don't think there will be any problem in merging it if/when the
kernel portion is accepted.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: [PATCH]IA64: assign a distinguishable label to uncached memory

[Jay Lan]

Simon Horman wrote:
> On Thu, Sep 11, 2008 at 04:00:08PM -0700, Jay Lan wrote:
>> Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
>> is denoted as "System RAM" in /proc/iomem, while memory of attribute
>> (EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
>>
>> The kexec utility then includes uncached memory as part of vmcore. The
>> kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal
>> "cached" access may cause MCAs.
>>
>> This patch would label memory with attribute of EFI_MEMORY_UC only as
>> "Uncached RAM" so that kexec would know not to include it in the vmcore.
>> I will submit a separate kexec-tools patch to the kexec list.
>>
>> Signed-off-by: Jay Lan <jlan@sgi.com>
> 
> Hi Jay,
> 
> I've taken a look on an RX2620, Tiger2 and Tiger4 and none of these
> machines have EFI memory regions that are covered by this new check. That
> is, any regions with the EFI_MEMORY_UC bit set in the attribute either also
> have other attibute bits set, or are of a type not covered by this.

Great! So the change affects most likely only SGI Altix machines.
Below is the EFI memory regions of one node of an Altix machine:

PAL_code   0000000001000000-0000000001FFFFFF  0000000000001000
8000000000000009
MemMapIO   00000000FF000000-00000000FFFFFFFF  0000000000001000
8000000000000001
Unusable   0000006000000000-000000600000FFFF  0000000000000010
0000000000000009
RT_data    0000006000010000-00000060000FFFFF  00000000000000F0
8000000000001001
BS_data    0000006000100000-00000060003FFFFF  0000000000000300
0000000000000001
RT_data    0000006000400000-0000006001FFFFFF  0000000000001C00
8000000000001009
RT_data    0000006002000000-0000006002FFFFFF  0000000000001000
8000000000000009
BS_data    0000006003000000-0000006033DFFFFF  0000000000030E00
0000000000000009
available  0000006033E00000-00000060F7FFFFFF  00000000000C4200
0000000000000009
MemMapIO   0000008000000000-0000009FFFFFFFFF  0000000002000000
8000000000000003

The first BS_data region starting at 0x0000006000100000 is the
case. That memory is part of Altix "fetchop" space (AKA mspec).

Since it does not affect IA64 machines you have, this patch should
be very safe, yet needed for Altix.

> 
> I strongly suspect that this is not a problem, but I wanted to bring it to
> your attention anyway. I can provide more detailed EFI information from any
> or all of these machines if you need it.
> 
> With regards to the kexec-tools portion of this patch, it looks fine to me
> and I don't think there will be any problem in merging it if/when the
> kernel portion is accepted.

Sounds great. Thanks for checking at your IA64 machines for me, Simon.

Regards,
jay

> 

Re: [PATCH]IA64: assign a distinguishable label to uncached memory

[Simon Horman]

On Mon, Sep 15, 2008 at 10:08:48AM -0700, Jay Lan wrote:
> Simon Horman wrote:
> > On Thu, Sep 11, 2008 at 04:00:08PM -0700, Jay Lan wrote:
> >> Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
> >> is denoted as "System RAM" in /proc/iomem, while memory of attribute
> >> (EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
> >>
> >> The kexec utility then includes uncached memory as part of vmcore. The
> >> kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal
> >> "cached" access may cause MCAs.
> >>
> >> This patch would label memory with attribute of EFI_MEMORY_UC only as
> >> "Uncached RAM" so that kexec would know not to include it in the vmcore.
> >> I will submit a separate kexec-tools patch to the kexec list.
> >>
> >> Signed-off-by: Jay Lan <jlan@sgi.com>
> > 
> > Hi Jay,
> > 
> > I've taken a look on an RX2620, Tiger2 and Tiger4 and none of these
> > machines have EFI memory regions that are covered by this new check. That
> > is, any regions with the EFI_MEMORY_UC bit set in the attribute either also
> > have other attibute bits set, or are of a type not covered by this.
> 
> Great! So the change affects most likely only SGI Altix machines.
> Below is the EFI memory regions of one node of an Altix machine:
> 
> PAL_code   0000000001000000-0000000001FFFFFF  0000000000001000
> 8000000000000009
> MemMapIO   00000000FF000000-00000000FFFFFFFF  0000000000001000
> 8000000000000001
> Unusable   0000006000000000-000000600000FFFF  0000000000000010
> 0000000000000009
> RT_data    0000006000010000-00000060000FFFFF  00000000000000F0
> 8000000000001001
> BS_data    0000006000100000-00000060003FFFFF  0000000000000300
> 0000000000000001
> RT_data    0000006000400000-0000006001FFFFFF  0000000000001C00
> 8000000000001009
> RT_data    0000006002000000-0000006002FFFFFF  0000000000001000
> 8000000000000009
> BS_data    0000006003000000-0000006033DFFFFF  0000000000030E00
> 0000000000000009
> available  0000006033E00000-00000060F7FFFFFF  00000000000C4200
> 0000000000000009
> MemMapIO   0000008000000000-0000009FFFFFFFFF  0000000002000000
> 8000000000000003
> 
> The first BS_data region starting at 0x0000006000100000 is the
> case. That memory is part of Altix "fetchop" space (AKA mspec).
> 
> Since it does not affect IA64 machines you have, this patch should
> be very safe, yet needed for Altix.

Thats what I was hoping your reaction would be.

Acked-by: Simon Horman <horms@verge.net.au>

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en