[Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[Sluder, Charles]

We recently moved from 2.4.9 to 2.4.19.  We encountered several problems
when trying to boot the kernel.

The first problem was a panic in put_gate_page(). The panic only occurs with
CONFIG_VIRTUAL_MEMMAP enabled. The panic results because there is not a pte
for the kernel data section.  We traced this back and found that
efi_memmap_walk() was indiscriminately "trimming" chunks out of the first
96MB of memory in the efi memory map. The problem appears to be that the
first_non_wb_addr variable is not being advanced properly as the code walks
through the efi memory descriptors. On the next pass through the outer loop
after a hole is encountered in the memmap, first_non_wb_addr is usually
pointing at one of the memory descriptors in the previous contiguous
segment. It calls the functions to trim the memory descriptor without taking
the memory descriptor previous to that into account. Basically the code goes
through a contiguous segment, finds a hole, and then, on the next pass,
trims a bunch of memory out of the contiguous segment. The problem only
occurs if there are numerous holes in the efi memory map. The panic will not
occur on a tiger.  The patch sets first_non_wb_addr to either the first non
write back address it finds or to the  start address in the first memory
descriptor after a hole. We do not fully understand all the uses for this
routine and are therefore not certain that this is the correct way to fix
this problem.

The second problem encountered is a hang trying to acquire the FACS global
lock. The arguments passed to the acquire and release macros, for the global
lock, changed slightly between 2.4.9 and 2.4.18. The result appears to be
that the address to the pointer to the global lock is being passed to the
macros as the lock address instead of the global lock address. We tried
several things to force the correct values to be passed to the macro, but
the only thing that has worked is to change the memory constraint on the
GLptr to a register constraint and modify the macro appropriately.  This
problem only occurs if the firmware supports the FACS global lock. The
problem will not occur on a tiger.

The third problem was an unsupported data reference fault when executing the
cmpxchg instruction, in the macros to acquire and release the above lock.
The global lock address passed to the macros was uncached. We have moved the
lock address into the cached memory region.  The lock is only used by these
macros so we don't belive this causes a problem unless there is something
lurking in the SAL that we are unaware of.

Comment and discussion are welcome. I am sure we would get it even if it
wasn't :-).

-chuck

Charles Sluder
Enterprise Unix Group
Unisys Corp.


diff -Naur UL.base/arch/ia64/kernel/efi.c linux.work/arch/ia64/kernel/efi.c
--- UL.base/arch/ia64/kernel/efi.c	2002-10-21 08:52:13.000000000 -0700
+++ linux.work/arch/ia64/kernel/efi.c	2002-11-01 14:01:21.000000000 -0800
@@ -247,13 +249,19 @@
 				if (check_md->phys_addr < granule_addr)
 					continue;
 
-				if (!(check_md->attribute & EFI_MEMORY_WB))
+
+				if (!(check_md->attribute & EFI_MEMORY_WB)){
+					first_non_wb_addr check_md->phys_addr;
 					break;	/* hit a non-WB region; stop
search */
+				}
 
-				if (check_md->phys_addr !first_non_wb_addr)
+				if (check_md->phys_addr !first_non_wb_addr){
+					first_non_wb_addr check_md->phys_addr;
 					break;	/* hit a memory hole; stop
search */
+				}
 
 				first_non_wb_addr += check_md->num_pages <<
EFI_PAGE_SHIFT;
 			}
 			/* round it down to the previous granule-boundary:
*/
 			first_non_wb_addr &= -IA64_GRANULE_SIZE;

 
diff -Naur UL.base/drivers/acpi/tables/tbconvrt.c
linux.work/drivers/acpi/tables/tbconvrt.c
--- UL.base/drivers/acpi/tables/tbconvrt.c	2002-10-21
08:52:13.000000000 -0700
+++ linux.work/drivers/acpi/tables/tbconvrt.c	2002-11-01
12:16:08.000000000 -0800
@@ -435,7 +435,8 @@
 
 	/* Copy fields to the new FACS */
 
-	acpi_gbl_common_fACS.global_lock = &(acpi_gbl_FACS->global_lock);
+	/* Make sure it's cached identity-mapped */
+	acpi_gbl_common_fACS.global_lock = (void
*)((ulong)&(acpi_gbl_FACS->global_lock) | PAGE_OFFSET);
 
 	if ((acpi_gbl_RSDP->revision < 2) ||
 		(acpi_gbl_FACS->length < 32) ||
 
diff -Naur UL.base/include/asm-ia64/acpi.h
linux.work/include/asm-ia64/acpi.h
--- UL.base/include/asm-ia64/acpi.h	2002-10-21 08:52:13.000000000 -0700
+++ linux.work/include/asm-ia64/acpi.h	2002-11-01 12:24:18.000000000 -0800
@@ -54,9 +54,10 @@
 #define ACPI_ENABLE_IRQS()  __sti()
 #define ACPI_FLUSH_CPU_CACHE()
 
+
 #define ACPI_ACQUIRE_GLOBAL_LOCK(GLptr, Acq) \
 	do { \
-	__asm__ volatile ("1:  ld4      r29=%1\n"  \
+	__asm__ volatile ("1:  ld4      r29=[%1]\n"  \
 		";;\n"                  \
 		"mov    ar.ccv=r29\n"   \
 		"mov    r2=r29\n"       \
@@ -68,7 +69,7 @@
 		";;\n"                  \
 		"add    r29=r29,r30\n"  \
 		";;\n"                  \
-		"cmpxchg4.acq   r30=%1,r29,ar.ccv\n" \
+		"cmpxchg4.acq   r30=[%1],r29,ar.ccv\n" \
 		";;\n"                  \
 		"cmp.eq p6,p7=r2,r30\n" \
 		"(p7) br.dpnt.few 1b\n" \
@@ -76,24 +77,24 @@
 		";;\n"                  \
 		"(p8) mov %0=-1\n"      \
 		"(p9) mov %0=r0\n"      \
-		:"=r"(Acq):"m"(GLptr):"r2","r29","r30","memory"); \
+
:"=r"(Acq):"r"(GLptr):"r2","r29","r30","p6","p7","p8","p9","ar.ccv","memory"
); \  
 	} while (0)
 
 #define ACPI_RELEASE_GLOBAL_LOCK(GLptr, Acq) \
 	do { \
-	__asm__ volatile ("1:  ld4      r29=%1\n" \
+        __asm__ volatile ("1:  ld4      r29=[%1]\n" \ 
 		";;\n"                  \
 		"mov    ar.ccv=r29\n"   \
 		"mov    r2=r29\n"       \
 		"and    r29=-4,r29\n"   \
 		";;\n"                  \
-		"cmpxchg4.acq   r30=%1,r29,ar.ccv\n" \
+                "cmpxchg4.rel   r30=[%1],r29,ar.ccv\n" \    
 		";;\n"                  \
 		"cmp.eq p6,p7=r2,r30\n" \
 		"(p7) br.dpnt.few 1b\n" \
 		"and    %0=1,r2\n"      \
 		";;\n"                  \
-		:"=r"(Acq):"m"(GLptr):"r2","r29","r30","memory"); \
+
:"=r"(Acq):"r"(GLptr):"r2","r29","r30","p6","p7","ar.ccv","memory"); \    
 	} while (0)
 
 const char *acpi_get_sysname (void);

RE: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[Van Maren, Kevin]

Chuck,

It looks like your mailer (my mailer?) munged the diff.  Can you
resend it as an attachment or something?

> We recently moved from 2.4.9 to 2.4.19.  We encountered 
> several problems
> when trying to boot the kernel.

[put_gate_page panic]

> The second problem encountered is a hang trying to acquire 
> the FACS global lock. 
...
> [we changed] the memory 
> constraint on the
> GLptr to a register constraint and modify the macro 
> appropriately.  This
> problem only occurs if the firmware supports the FACS global lock. The
> problem will not occur on a tiger.

With the memory constraint, the compiler passes in a register that points
to the memory location (which the compiler creates on the stack) that
contains the pointer value.  Using a register constraint "fixes" the
code that assumes that the input register contains the pointer value, not
a pointer to the value.

It does not occur on the tiger because the tiger does not support this lock?

Note that you also fixed the unlock to use release semantics instead of
acquire semantics.

> The third problem was an unsupported data reference fault 
> when executing the
> cmpxchg instruction, in the macros to acquire and release the 
> above lock.
> The global lock address passed to the macros was uncached. We 
> have moved the
> lock address into the cached memory region.  The lock is only 
> used by these
> macros so we don't belive this causes a problem unless there 
> is something
> lurking in the SAL that we are unaware of.

This is because the address was calculated based on the mapping in
region 6/"C" segment, instead of region 7/"E" segment, and cmpxchg
is only supported for "WB"/cacheable memory (region 7, not region 6).

Seems kindof a hack to OR in PAGE_OFFSET and have it "magically" change
the 0xC000... to 0xE000...  But I still don't have a better idea.

> -	acpi_gbl_common_fACS.global_lock = &(acpi_gbl_FACS->global_lock);
> +	/* Make sure it's cached identity-mapped */
> +	acpi_gbl_common_fACS.global_lock = (void
*)((ulong)&(acpi_gbl_FACS->global_lock) | PAGE_OFFSET);

Kevin

Re: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[David Mosberger]

>>>>> On Fri, 1 Nov 2002 16:14:43 -0600, "Sluder, Charles" <Charles.Sluder@UNISYS.com> said:

  Charles> The first problem was a panic in put_gate_page(). The panic
  Charles> only occurs with CONFIG_VIRTUAL_MEMMAP enabled. The panic
  Charles> results because there is not a pte for the kernel data
  Charles> section.  We traced this back and found that
  Charles> efi_memmap_walk() was indiscriminately "trimming" chunks
  Charles> out of the first 96MB of memory in the efi memory map. The
  Charles> problem appears to be that the first_non_wb_addr variable
  Charles> is not being advanced properly as the code walks through
  Charles> the efi memory descriptors. On the next pass through the
  Charles> outer loop after a hole is encountered in the memmap,
  Charles> first_non_wb_addr is usually pointing at one of the memory
  Charles> descriptors in the previous contiguous segment. It calls
  Charles> the functions to trim the memory descriptor without taking
  Charles> the memory descriptor previous to that into
  Charles> account. Basically the code goes through a contiguous
  Charles> segment, finds a hole, and then, on the next pass, trims a
  Charles> bunch of memory out of the contiguous segment. The problem
  Charles> only occurs if there are numerous holes in the efi memory
  Charles> map. The panic will not occur on a tiger.  The patch sets
  Charles> first_non_wb_addr to either the first non write back
  Charles> address it finds or to the start address in the first
  Charles> memory descriptor after a hole. We do not fully understand
  Charles> all the uses for this routine and are therefore not certain
  Charles> that this is the correct way to fix this problem.

Can you provide a specific example of a (simple) memory map that you
believe causes problems?  It's probably sufficient to give descriptors
for one or two granules (both the descriptor range & type are needed).

Thanks,

	--david

Re: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[David Mosberger]

>>>>> On Fri, 1 Nov 2002 16:14:43 -0600, "Sluder, Charles" <Charles.Sluder@UNISYS.com> said:

  Sluder> The first problem was a panic in put_gate_page(). The panic
  Sluder> only occurs with CONFIG_VIRTUAL_MEMMAP enabled. The panic
  Sluder> results because there is not a pte for the kernel data
  Sluder> section.  We traced this back and found that
  Sluder> efi_memmap_walk() was indiscriminately "trimming" chunks out
  Sluder> of the first 96MB of memory in the efi memory map.

Yes, indeed, there was a bug there: the problem was that after
rounding down first_non_wb_addr to a granule-boundary, the code failed
to trim the top of all the descriptors that were part of the current
contiguous run of wb-memory.  This was part of an optimization, but
the optimization doesn't work in more complicated cases... ;-(

The patch below should fix the problem.  Can you try it and let me
know how it works?

  Sluder> The second problem encountered is a hang trying to acquire
  Sluder> the FACS global lock. The arguments passed to the acquire
  Sluder> and release macros, for the global lock, changed slightly
  Sluder> between 2.4.9 and 2.4.18. The result appears to be that the
  Sluder> address to the pointer to the global lock is being passed to
  Sluder> the macros as the lock address instead of the global lock
  Sluder> address. We tried several things to force the correct values
  Sluder> to be passed to the macro, but the only thing that has
  Sluder> worked is to change the memory constraint on the GLptr to a
  Sluder> register constraint and modify the macro appropriately.
  Sluder> This problem only occurs if the firmware supports the FACS
  Sluder> global lock. The problem will not occur on a tiger.

Yes, this clearly seems to be a bug in the ACPI code.  It's wrong to
use the "m" constraint there.  Can you send to is patch to Andy Grover
as well so it gets into ACPI mainline?

  Sluder> The third problem was an unsupported data reference fault
  Sluder> when executing the cmpxchg instruction, in the macros to
  Sluder> acquire and release the above lock.  The global lock address
  Sluder> passed to the macros was uncached. We have moved the lock
  Sluder> address into the cached memory region.  The lock is only
  Sluder> used by these macros so we don't belive this causes a
  Sluder> problem unless there is something lurking in the SAL that we
  Sluder> are unaware of.

This one is interesting.  I'm no ACPI expert but my understanding is
that the FACS table gets loaded in
tables/tbget.c:acpi_tb_get_this_table() where it gets mapped via a
call to acpi_os_map_memory().  The latter does:

	if (EFI_MEMORY_WB & efi_mem_attributes(phys)) {
		*virt = phys_to_virt(phys);
	} else {
		*virt = ioremap(phys, size);
	}

so, if FACS resides in a memory area marked WB, it *should* get mapped
into cachable space.  Can you tell us what the physical address of the
table is?  Let's hope it's not inside a granule with a hole.
Otherwise, you'll have a real problem with that machine (it wouldn't
be safe to access the table through cacheble space).

	--david

=== arch/ia64/kernel/efi.c 1.16 vs edited ==--- 1.16/arch/ia64/kernel/efi.c	Wed Sep 25 19:04:16 2002
+++ edited/arch/ia64/kernel/efi.c	Wed Nov  6 15:27:03 2002
@@ -306,7 +306,7 @@
 		u64 start;
 		u64 end;
 	} prev, curr;
-	void *efi_map_start, *efi_map_end, *p, *q;
+	void *efi_map_start, *efi_map_end, *p, *q, *r;
 	efi_memory_desc_t *md, *check_md;
 	u64 efi_desc_size, start, end, granule_addr, first_non_wb_addr = 0;
 
@@ -351,11 +351,10 @@
 
 			if (!(first_non_wb_addr > granule_addr))
 				continue;	/* couldn't find enough contiguous memory */
-		}
-
-		/* BUG_ON((md->phys_addr >> IA64_GRANULE_SHIFT) < first_non_wb_addr); */
 
-		trim_top(md, first_non_wb_addr);
+			for (r = p; r < q; r += efi_desc_size)
+				trim_top(r, first_non_wb_addr);
+		}
 
 		if (is_available_memory(md)) {
 			if (md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) > mem_limit) {

Re: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[David Mosberger]

>>>>> On Wed, 6 Nov 2002 15:31:21 -0800, David Mosberger <davidm@linux.hpl.hp.com> said:

  David> Yes, this clearly seems to be a bug in the ACPI code.  It's
  David> wrong to use the "m" constraint there.  Can you send to is
  David> patch to Andy Grover as well so it gets into ACPI mainline?

Oops, never mind.  I thought the offending file was in the
drivers/acpi subtree.  Since it's in asm-ia64/acpi.h, I can fix it.

Thanks,

	--david

RE: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[Sluder, Charles]

I tried the patch and it gets rid of the panic.  Before and after dumps of
the memory map are below. The SAL and ACPI tables are being trimmed from the
memory map. That is why the FACS global lock is mapped uncached. Debug from
acpi_map_os_memory is also include below.

Shouldn't the trim code ignore runtime memory? 

-chuck



EFI v1.10 by INTEL: SALsystab=0x7facf760 ACPI=0x7faeb048 ACPI 2.0=0xf7300
MPS=0x7fadc3b0 SMBIOS=0xf72b0
mem00: type=4, attr=0x9, range=[0x0000000000000000-0x0000000000001000) (0MB)
mem01: type=7, attr=0x9, range=[0x0000000000001000-0x000000000008a000) (0MB)
mem02: type=4, attr=0x9, range=[0x000000000008a000-0x00000000000a0000) (0MB)
mem03: type=5, attr=0x8000000000000009,
range=[0x00000000000c0000-0x0000000000100000) (0MB)
mem04: type=7, attr=0x9, range=[0x0000000000100000-0x0000000004400000)
(67MB)
mem05: type=2, attr=0x9, range=[0x0000000004400000-0x0000000004bc7000) (7MB)
mem06: type=7, attr=0x9, range=[0x0000000004bc7000-0x000000007f77e000)
(1963MB)
mem07: type=6, attr=0x8000000000000009,
range=[0x000000007f77e000-0x000000007fb94000) (4MB)
mem08: type=6, attr=0x8000000000000009,
range=[0x000000007fb94000-0x000000007fb95000) (0MB)
mem09: type=6, attr=0x8000000000000009,
range=[0x000000007fb95000-0x000000007fc00000) (0MB)
mem10: type\x13, attr=0x8000000000000009,
range=[0x000000007fc00000-0x000000007fc3a000) (0MB)
mem11: type=7, attr=0x9, range=[0x000000007fc3a000-0x000000007fea0000) (2MB)
mem12: type=5, attr=0x8000000000000009,
range=[0x000000007fea0000-0x000000007fea8000) (0MB)
mem13: type=7, attr=0x9, range=[0x000000007fea8000-0x000000007feab000) (0MB)
mem14: type=5, attr=0x8000000000000009,
range=[0x000000007feab000-0x000000007ffff000) (1MB)
mem15: type=6, attr=0x8000000000000001,
range=[0x00000000ff400000-0x0000000100000000) (12MB)
mem16: type=7, attr=0x9, range=[0x0000000100000000-0x00000003fffff000)
(12287MB)
mem17: type=6, attr=0x8000000000000009,
range=[0x00000003fffff000-0x0000000400000000) (0MB)
mem18: type=7, attr=0x9, range=[0x0000000480000000-0x00000004fef4c000)
(2031MB)
mem19: type=2, attr=0x9, range=[0x00000004fef4c000-0x00000004fef4d000) (0MB)
mem20: type=7, attr=0x9, range=[0x00000004fef4d000-0x00000004fef62000) (0MB)
mem21: type=2, attr=0x9, range=[0x00000004fef62000-0x00000004fef68000) (0MB)
mem22: type=7, attr=0x9, range=[0x00000004fef68000-0x00000004fef69000) (0MB)
mem23: type=2, attr=0x9, range=[0x00000004fef69000-0x00000004fef6b000) (0MB)
mem24: type=7, attr=0x9, range=[0x00000004fef6b000-0x00000004fef70000) (0MB)
mem25: type=2, attr=0x9, range=[0x00000004fef70000-0x00000004fef72000) (0MB)
mem26: type=7, attr=0x9, range=[0x00000004fef72000-0x00000004fef77000) (0MB)
mem27: type=2, attr=0x9, range=[0x00000004fef77000-0x00000004fef79000) (0MB)
mem28: type=7, attr=0x9, range=[0x00000004fef79000-0x00000004fef7e000) (0MB)
mem29: type=2, attr=0x9, range=[0x00000004fef7e000-0x00000004fef80000) (0MB)
mem30: type=7, attr=0x9, range=[0x00000004fef80000-0x00000004fef85000) (0MB)
mem31: type=2, attr=0x9, range=[0x00000004fef85000-0x00000004fef87000) (0MB)
mem32: type=7, attr=0x9, range=[0x00000004fef87000-0x00000004fef8c000) (0MB)
mem33: type=2, attr=0x9, range=[0x00000004fef8c000-0x00000004fef8e000) (0MB)
mem34: type=7, attr=0x9, range=[0x00000004fef8e000-0x00000004fef93000) (0MB)
mem35: type=2, attr=0x9, range=[0x00000004fef93000-0x00000004fef95000) (0MB)
mem36: type=7, attr=0x9, range=[0x00000004fef95000-0x00000004fef98000) (0MB)
mem37: type=2, attr=0x9, range=[0x00000004fef98000-0x00000004fefa2000) (0MB)
mem38: type=1, attr=0x9, range=[0x00000004fefa2000-0x00000004ff000000) (0MB)
mem39: type=7, attr=0x9, range=[0x00000004ff000000-0x00000004ff456000) (4MB)
mem40: type=4, attr=0x9, range=[0x00000004ff456000-0x00000004ff801000) (3MB)
mem41: type=7, attr=0x9, range=[0x00000004ff801000-0x00000004ff91b000) (1MB)
mem42: type=4, attr=0x9, range=[0x00000004ff91b000-0x00000004ffa00000) (0MB)
mem43: type=7, attr=0x9, range=[0x00000004ffa00000-0x00000004ffe12000) (4MB)
mem44: type=5, attr=0x8000000000000009,
range=[0x00000004ffe12000-0x00000004ffe80000) (0MB)
mem45: type=7, attr=0x9, range=[0x00000004ffe80000-0x00000004fffc1000) (1MB)
mem46: type=6, attr=0x8000000000000009,
range=[0x00000004fffc1000-0x0000000500000000) (0MB)
mem47: type\x12, attr=0x8000000000000001,
range=[0x00000ffffc000000-0x0000100000000000) (64MB)



mem00: type=4, attr=0x9, range=[0x0000000000000000-0x0000000000001000) (0MB)
mem01: type=7, attr=0x9, range=[0x000000000008a000-0x000000000008a000) (0MB)
mem02: type=4, attr=0x9, range=[0x000000000008a000-0x00000000000a0000) (0MB)
mem03: type=5, attr=0x8000000000000009,
range=[0x00000000000c0000-0x0000000000100000) (0MB)
mem04: type=7, attr=0x9, range=[0x0000000001000000-0x0000000004400000)
(52MB)
mem05: type=2, attr=0x9, range=[0x0000000004400000-0x0000000004bc7000) (7MB)
mem06: type=7, attr=0x9, range=[0x0000000004bc7000-0x000000007f000000)
(1956MB)
mem07: type=6, attr=0x8000000000000009,
range=[0x000000007f77e000-0x000000007f77e000) (0MB)
mem08: type=6, attr=0x8000000000000009,
range=[0x000000007fb94000-0x000000007fb94000) (0MB)
mem09: type=6, attr=0x8000000000000009,
range=[0x000000007fb95000-0x000000007fb95000) (0MB)
mem10: type\x13, attr=0x8000000000000009,
range=[0x000000007fc00000-0x000000007fc00000) (0MB)
mem11: type=7, attr=0x9, range=[0x000000007fc3a000-0x000000007fc3a000) (0MB)
mem12: type=5, attr=0x8000000000000009,
range=[0x000000007fea0000-0x000000007fea0000) (0MB)
mem13: type=7, attr=0x9, range=[0x000000007fea8000-0x000000007fea8000) (0MB)
mem14: type=5, attr=0x8000000000000009,
range=[0x000000007feab000-0x000000007feab000) (0MB)
mem15: type=6, attr=0x8000000000000001,
range=[0x00000000ff400000-0x0000000100000000) (12MB)
mem16: type=7, attr=0x9, range=[0x0000000100000000-0x00000003fffff000)
(12287MB)
mem17: type=6, attr=0x8000000000000009,
range=[0x00000003fffff000-0x0000000400000000) (0MB)
mem18: type=7, attr=0x9, range=[0x0000000480000000-0x00000004fef4c000)
(2031MB)
mem19: type=2, attr=0x9, range=[0x00000004fef4c000-0x00000004fef4d000) (0MB)
mem20: type=7, attr=0x9, range=[0x00000004fef4d000-0x00000004fef62000) (0MB)
mem21: type=2, attr=0x9, range=[0x00000004fef62000-0x00000004fef68000) (0MB)
mem22: type=7, attr=0x9, range=[0x00000004fef68000-0x00000004fef69000) (0MB)
mem23: type=2, attr=0x9, range=[0x00000004fef69000-0x00000004fef6b000) (0MB)
mem24: type=7, attr=0x9, range=[0x00000004fef6b000-0x00000004fef70000) (0MB)
mem25: type=2, attr=0x9, range=[0x00000004fef70000-0x00000004fef72000) (0MB)
mem26: type=7, attr=0x9, range=[0x00000004fef72000-0x00000004fef77000) (0MB)
mem27: type=2, attr=0x9, range=[0x00000004fef77000-0x00000004fef79000) (0MB)
mem28: type=7, attr=0x9, range=[0x00000004fef79000-0x00000004fef7e000) (0MB)
mem29: type=2, attr=0x9, range=[0x00000004fef7e000-0x00000004fef80000) (0MB)
mem30: type=7, attr=0x9, range=[0x00000004fef80000-0x00000004fef85000) (0MB)
mem31: type=2, attr=0x9, range=[0x00000004fef85000-0x00000004fef87000) (0MB)
mem32: type=7, attr=0x9, range=[0x00000004fef87000-0x00000004fef8c000) (0MB)
mem33: type=2, attr=0x9, range=[0x00000004fef8c000-0x00000004fef8e000) (0MB)
mem34: type=7, attr=0x9, range=[0x00000004fef8e000-0x00000004fef93000) (0MB)
mem35: type=2, attr=0x9, range=[0x00000004fef93000-0x00000004fef95000) (0MB)
mem36: type=7, attr=0x9, range=[0x00000004fef95000-0x00000004fef98000) (0MB)
mem37: type=2, attr=0x9, range=[0x00000004fef98000-0x00000004fefa2000) (0MB)
mem38: type=1, attr=0x9, range=[0x00000004fefa2000-0x00000004ff000000) (0MB)
mem39: type=7, attr=0x9, range=[0x00000004ff000000-0x00000004ff456000) (4MB)
mem40: type=4, attr=0x9, range=[0x00000004ff456000-0x00000004ff801000) (3MB)
mem41: type=7, attr=0x9, range=[0x00000004ff801000-0x00000004ff91b000) (1MB)
mem42: type=4, attr=0x9, range=[0x00000004ff91b000-0x00000004ffa00000) (0MB)
mem43: type=7, attr=0x9, range=[0x00000004ffa00000-0x00000004ffe12000) (4MB)
mem44: type=5, attr=0x8000000000000009,
range=[0x00000004ffe12000-0x00000004ffe80000) (0MB)
mem45: type=7, attr=0x9, range=[0x00000004ffe80000-0x00000004fffc1000) (1MB)
mem46: type=6, attr=0x8000000000000009,
range=[0x00000004fffc1000-0x0000000500000000) (0MB)
mem47: type\x12, attr=0x8000000000000001,
range=[0x00000ffffc000000-0x0000100000000000) (64MB)


ACPI: RSDP (v000 PTLTD                      ) @ 0x00000000000f7300
ACPI: RSDT (v001 PTLTD    RSDT   01540.00000) @ 0x000000007fad0e60
ACPI: FADT (v003 PTEC   Tiger4   01540.00000) @ 0x000000007fad9ba4
ACPI: SRAT (v001 UNISYS   SRAT   01540.00000) @ 0x000000007fad9c98
ACPI: IPPT (v001 UNISYS   IPPT   01540.00000) @ 0x000000007fad9df8
ACPI: MADT (v001 PTLTD    APIC   01540.00000) @ 0x000000007fad9e32
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 01540.00000) @ 0x000000007fad9f88
ACPI: SPCR (v001 PTLTD  $UCRTBL$ 01540.00000) @ 0x000000007fad9fb0


acpi_os_map_memory:phys_to_virt: phys\0000000000f7300 virtà000000000f7300
attribute€00000000000009
acpi_os_map_memory:ioremap: phys\00000007fad0e60 virtÀ0000007fad0e60
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad0e60 virtÀ0000007fad0e60
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad9ba4 virtÀ0000007fad9ba4
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad9ba4 virtÀ0000007fad9ba4
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad9c98 virtÀ0000007fad9c98
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad9df8 virtÀ0000007fad9df8
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fada830 virtÀ0000007fada830
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fada830 virtÀ0000007fada830
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad0ef0 virtÀ0000007fad0ef0
attribute= 0000000000000000
acpi_os_map_memory:ioremap: phys\00000007fad0ef0 virtÀ0000007fad0ef0
attribute= 0000000000000000

-----Original Message-----
From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
Sent: Wednesday, November 06, 2002 4:31 PM
To: Sluder, Charles
Cc: linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap


>>>>> On Fri, 1 Nov 2002 16:14:43 -0600, "Sluder, Charles"
<Charles.Sluder@UNISYS.com> said:

  Sluder> The first problem was a panic in put_gate_page(). The panic
  Sluder> only occurs with CONFIG_VIRTUAL_MEMMAP enabled. The panic
  Sluder> results because there is not a pte for the kernel data
  Sluder> section.  We traced this back and found that
  Sluder> efi_memmap_walk() was indiscriminately "trimming" chunks out
  Sluder> of the first 96MB of memory in the efi memory map.

Yes, indeed, there was a bug there: the problem was that after
rounding down first_non_wb_addr to a granule-boundary, the code failed
to trim the top of all the descriptors that were part of the current
contiguous run of wb-memory.  This was part of an optimization, but
the optimization doesn't work in more complicated cases... ;-(

The patch below should fix the problem.  Can you try it and let me
know how it works?

  Sluder> The second problem encountered is a hang trying to acquire
  Sluder> the FACS global lock. The arguments passed to the acquire
  Sluder> and release macros, for the global lock, changed slightly
  Sluder> between 2.4.9 and 2.4.18. The result appears to be that the
  Sluder> address to the pointer to the global lock is being passed to
  Sluder> the macros as the lock address instead of the global lock
  Sluder> address. We tried several things to force the correct values
  Sluder> to be passed to the macro, but the only thing that has
  Sluder> worked is to change the memory constraint on the GLptr to a
  Sluder> register constraint and modify the macro appropriately.
  Sluder> This problem only occurs if the firmware supports the FACS
  Sluder> global lock. The problem will not occur on a tiger.

Yes, this clearly seems to be a bug in the ACPI code.  It's wrong to
use the "m" constraint there.  Can you send to is patch to Andy Grover
as well so it gets into ACPI mainline?

  Sluder> The third problem was an unsupported data reference fault
  Sluder> when executing the cmpxchg instruction, in the macros to
  Sluder> acquire and release the above lock.  The global lock address
  Sluder> passed to the macros was uncached. We have moved the lock
  Sluder> address into the cached memory region.  The lock is only
  Sluder> used by these macros so we don't belive this causes a
  Sluder> problem unless there is something lurking in the SAL that we
  Sluder> are unaware of.

This one is interesting.  I'm no ACPI expert but my understanding is
that the FACS table gets loaded in
tables/tbget.c:acpi_tb_get_this_table() where it gets mapped via a
call to acpi_os_map_memory().  The latter does:

	if (EFI_MEMORY_WB & efi_mem_attributes(phys)) {
		*virt = phys_to_virt(phys);
	} else {
		*virt = ioremap(phys, size);
	}

so, if FACS resides in a memory area marked WB, it *should* get mapped
into cachable space.  Can you tell us what the physical address of the
table is?  Let's hope it's not inside a granule with a hole.
Otherwise, you'll have a real problem with that machine (it wouldn't
be safe to access the table through cacheble space).

	--david

=== arch/ia64/kernel/efi.c 1.16 vs edited ==--- 1.16/arch/ia64/kernel/efi.c	Wed Sep 25 19:04:16 2002
+++ edited/arch/ia64/kernel/efi.c	Wed Nov  6 15:27:03 2002
@@ -306,7 +306,7 @@
 		u64 start;
 		u64 end;
 	} prev, curr;
-	void *efi_map_start, *efi_map_end, *p, *q;
+	void *efi_map_start, *efi_map_end, *p, *q, *r;
 	efi_memory_desc_t *md, *check_md;
 	u64 efi_desc_size, start, end, granule_addr, first_non_wb_addr = 0;
 
@@ -351,11 +351,10 @@
 
 			if (!(first_non_wb_addr > granule_addr))
 				continue;	/* couldn't find enough
contiguous memory */
-		}
-
-		/* BUG_ON((md->phys_addr >> IA64_GRANULE_SHIFT) <
first_non_wb_addr); */
 
-		trim_top(md, first_non_wb_addr);
+			for (r = p; r < q; r += efi_desc_size)
+				trim_top(r, first_non_wb_addr);
+		}
 
 		if (is_available_memory(md)) {
 			if (md->phys_addr + (md->num_pages <<
EFI_PAGE_SHIFT) > mem_limit) {

RE: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[David Mosberger]

>>>>> On Wed, 6 Nov 2002 20:52:40 -0600 , "Sluder, Charles" <Charles.Sluder@UNISYS.com> said:

  Chuck> I tried the patch and it gets rid of the panic.  Before and
  Chuck> after dumps of the memory map are below. The SAL and ACPI
  Chuck> tables are being trimmed from the memory map. That is why the
  Chuck> FACS global lock is mapped uncached. Debug from
  Chuck> acpi_map_os_memory is also include below.

  Chuck> Shouldn't the trim code ignore runtime memory?

No, it can't ignore it.  There is a real problem here: the ACPI table
lies in a 64MB granule which has a hole (because of the missing 4KB
page at 0x000000007ffff000).  Because of that, the kernel simply
cannot safely access that memory via a write-back mapping (the reason
is that the processor prefetch or a speculative load might otherwise
access the hole and MCA while doing that).

So as it stands, Linux simply won't be able to work correctly on a
machine with this kind of memory map.  Can you move the firmware
tables to a granule which is fully populated?

	--david

RE: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap

[Sluder, Charles]

I submitted a problem report on the firmware. Will have to wait and see if
they will make changes.

Thanks for solving our problems. The effort is very much appreciated.

-chuck

-----Original Message-----
From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
Sent: Wednesday, November 06, 2002 8:13 PM
To: Sluder, Charles
Cc: linux-ia64@linuxia64.org
Subject: RE: [Linux-ia64] [PATCH]ACPI fACS global lock & virtual memmap


>>>>> On Wed, 6 Nov 2002 20:52:40 -0600 , "Sluder, Charles"
<Charles.Sluder@UNISYS.com> said:

  Chuck> I tried the patch and it gets rid of the panic.  Before and
  Chuck> after dumps of the memory map are below. The SAL and ACPI
  Chuck> tables are being trimmed from the memory map. That is why the
  Chuck> FACS global lock is mapped uncached. Debug from
  Chuck> acpi_map_os_memory is also include below.

  Chuck> Shouldn't the trim code ignore runtime memory?

No, it can't ignore it.  There is a real problem here: the ACPI table
lies in a 64MB granule which has a hole (because of the missing 4KB
page at 0x000000007ffff000).  Because of that, the kernel simply
cannot safely access that memory via a write-back mapping (the reason
is that the processor prefetch or a speculative load might otherwise
access the hole and MCA while doing that).

So as it stands, Linux simply won't be able to work correctly on a
machine with this kind of memory map.  Can you move the firmware
tables to a granule which is fully populated?

	--david

_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64