Skip to contentSkip to conversation

temp. mem mappings

DISCUSSION cohutta 3 participants 4 messages Jun 8, 2001 Memory management

lore
Share & tools
lore

cohutta

author
#0 lore raw
Quoted 10 lines

===== Original Message From "Stephen C. Tweedie" <[email protected]> ===== Hi,

Quoted 4 lines · cohutta

I think this is part of the problem: on my 1 GB system, the ACPI tables are at physical 0x3fffxxxx == virtual 0xffffxxxx, which could conflict with the APIC and IOAPIC mappings (from fixmap.h).

Quoted 4 lines

Shouldn't be --- the fixmaps should be part of the kernel's dynamic virtual area, which is not identity mapped. You can still map those physical addresses via kmap() on a highmem system (and a 1GB machine should be running a highmem kernel).

Well i now have a 768 MB machine, but i don't think that makes a big difference with the problem that i am seeing in mapping this ACPI memory early in setup_arch() [x86].

Quoted 7 lines
Quoted 2 lines

Well, i'm talking about physical memory, but it's marked as ACPI data.

If it is marked PG_Reserved, then ioremap() will work on it despite it being inside the normal physical memory area. If not, kmap() will still work.

Quoted 8 lines
Quoted 5 lines

Another part of the problem is that I need to do this early in arch/i386/kernel/setup.c::setup_arch(), like between calls to paging_init() and init_apic_mappings(). I can't use ioremap() here can i? ioremap() calls get_vm_area() which calls kmalloc(), and i don't think i can use kmalloc() just yet.

Right --- you can use alloc_pages but we haven't done the initialisation of the kmalloc slabsl by this point.

My testing indicates that i can't use __get_free_page(GFP_KERNEL) any time during setup_arch() [still x86]. It causes a BUG in slab.c (line 920) [linux 2.4.5]. Did I misunderstand you? Do you have another suggestion?

[for others who need it, not Stephen:
__get_free_page() -> __get_free_pages() -> alloc_pages() -> __alloc_pages() ]

Quoted 1 line

_Why_ do you need access to the ACPI tables so early, though?

ACPI tables have much to say about booting on newer x86 systems. I'll try to be more specific later, when i can.

Quoted 2 lines

Cheers,
Stephen

Thanks Stephen.
/c/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

#1 lore raw
Quoted 33 lines · cohutta
Quoted 11 lines

===== Original Message From "Stephen C. Tweedie" <[email protected]> ===== Hi,

Quoted 4 lines · cohutta

I think this is part of the problem: on my 1 GB system, the ACPI tables are at physical 0x3fffxxxx == virtual 0xffffxxxx, which could conflict with the APIC and IOAPIC mappings (from fixmap.h).

Quoted 4 lines

Shouldn't be --- the fixmaps should be part of the kernel's dynamic virtual area, which is not identity mapped. You can still map those physical addresses via kmap() on a highmem system (and a 1GB machine should be running a highmem kernel).

Well i now have a 768 MB machine, but i don't think that makes a big difference with the problem that i am seeing in mapping this ACPI memory early in setup_arch() [x86].

Quoted 13 lines
Quoted 2 lines

Well, i'm talking about physical memory, but it's marked as ACPI data.

If it is marked PG_Reserved, then ioremap() will work on it despite it being inside the normal physical memory area. If not, kmap() will still work.

Quoted 5 lines

Another part of the problem is that I need to do this early in arch/i386/kernel/setup.c::setup_arch(), like between calls to paging_init() and init_apic_mappings(). I can't use ioremap() here can i? ioremap() calls get_vm_area() which calls kmalloc(), and i don't think i can use kmalloc() just yet.

Quoted 7 lines
Quoted 2 lines

Right --- you can use alloc_pages but we haven't done the initialisation of the kmalloc slabsl by this point.

My testing indicates that i can't use __get_free_page(GFP_KERNEL) any time during setup_arch() [still x86]. It causes a BUG in slab.c (line 920) [linux 2.4.5]. Did I misunderstand you? Do you have another suggestion?

Oops. You can't use __get_free_page() or alloc_pages() until mem_init() is called, which occurs in main/init.c:start_kernel() quite some time after setup_arch() has happened.

If you need pages before mem_init() happens, but after paging_init() has completed in setup_arch(), then use alloc_bootmem()/free_bootmem(). Any bootmem you alloc and don't free will end up being reserved.

-- Joe

-- Joseph A. Knapka
"You know how many remote castles there are along the gorges? You
can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. * --
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

#2 lore raw
In reply to cohutta

Hi,

Quoted 6 lines · cohutta
Quoted 2 lines

Right --- you can use alloc_pages but we haven't done the initialisation of the kmalloc slabsl by this point.

My testing indicates that i can't use __get_free_page(GFP_KERNEL) any time during setup_arch() [still x86]. It causes a BUG in slab.c (line 920) [linux 2.4.5].

After paging_init(), it should be OK --- as long as there is enough memory that you don't end up calling the VM try_to_free_page routines. Those will definitely choke this early in boot.

Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

#3 lore raw
Quoted 8 lines · Stephen C. Tweedie

Hi,

Quoted 3 lines · cohutta
Quoted 2 lines

Right --- you can use alloc_pages but we haven't done the initialisation of the kmalloc slabsl by this point.

Quoted 7 lines
Quoted 3 lines

My testing indicates that i can't use __get_free_page(GFP_KERNEL) any time during setup_arch() [still x86]. It causes a BUG in slab.c (line 920) [linux 2.4.5].

After paging_init(), it should be OK --- as long as there is enough memory that you don't end up calling the VM try_to_free_page routines. Those will definitely choke this early in boot.

But we don't actually give the zone allocator any free pages until mem_init().

- Joe

-- Joseph A. Knapka
"You know how many remote castles there are along the gorges? You
can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. * --
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/