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

David Mosberger
2002-11-06T17:32:43Z

>>>>> 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