RE: temp. mem mappings

RE: temp. mem mappings

[cohutta]

>===== Original Message From "Joseph A. Knapka" <jknapka@earthlink.net> =====
>"Stephen C. Tweedie" wrote:
>>
>> Hi,
>>
>> On Thu, Jun 07, 2001 at 09:38:06PM -0400, cohutta wrote:
>>
>> > >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.
>
>But we don't actually give the zone allocator any free pages
>until mem_init().

Right, so what Stephen warned about is happening:
__get_free_page() causes a BUG in slab.c via __alloc_pages()
-> try_to_free_pages() -> do_try_to_free_pages()
-> shrink_dcache_memory() -> kmem_cache_shrink() -> BUG().

/c/

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

Re: temp. mem mappings

[Eric W. Biederman]

I don't know if this has been resolved but I believe the correct idiom
to read the ACPI table would be:
kmap(virt_to_page(phys_to_virt(address)));

And then kunmap it when you are done.

Eric

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

RE: temp. mem mappings

[cohutta]

>===== Original Message From "Stephen C. Tweedie" <sct@redhat.com> =====
>Hi,
>
>On Wed, Jun 06, 2001 at 05:14:26PM -0400, cohutta wrote:
>
>> 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).
>
>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].

>> 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.
>
>> 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() ]

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

>Cheers,
> Stephen

Thanks Stephen.
/c/

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

Re: temp. mem mappings

[Joseph A. Knapka]

cohutta wrote:
> 
> >===== Original Message From "Stephen C. Tweedie" <sct@redhat.com> =====
> >Hi,
> >
> >On Wed, Jun 06, 2001 at 05:14:26PM -0400, cohutta wrote:
> >
> >> 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).
> >
> >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].
> 
> >> 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.
> >
> >> 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?

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: temp. mem mappings

[Stephen C. Tweedie]

Hi,

On Thu, Jun 07, 2001 at 09:38:06PM -0400, cohutta wrote:

> >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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: temp. mem mappings

[Joseph A. Knapka]

"Stephen C. Tweedie" wrote:
> 
> Hi,
> 
> On Thu, Jun 07, 2001 at 09:38:06PM -0400, cohutta wrote:
> 
> > >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.

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

RE: temp. mem mappings

[cohutta]

>===== Original Message From "Stephen C. Tweedie" <sct@redhat.com> =====
>Hi,
>
>On Tue, Jun 05, 2001 at 04:42:52PM -0400, cohutta wrote:
>
>> I don't really want to play with the page tables if i can help it.
>> I didn't use ioremap() because it's real system memory, not IO bus
>> memory.
>>
>> How much normal memory is identity-mapped at boot on x86?
>> Is it more than 8 MB?
>
>> I'm trying to read some ACPI tables, like the FACP.
>> On my system, this is at physical address 0x3fffd7d7 (e.g.).
>
>It depends at what time during boot.  Some ACPI memory is reusable
>once the system boots: the kernel parses the table then frees up the
>memory which the BIOS initialised.
>
>VERY early in boot, while the VM is still getting itself set up, there
>is only a minimal mapping set up by the boot loader code.  However,
>once the VM is initialised far enough to let you play with page
>tables, all memory will be identity-mapped up to just below the 1GB
>watermark.

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).
I removed 256 MB, but i still have a few problems.

>> kmap() ends up calling set_pte(), which is close to what i am
>> already doing.  i'm having a problem on the unmap side when i
>> am done with the temporary mapping.
>
>kunmap().  :-)  But kmap only works on CONFIG_HIGHMEM kernel builds.
>On kernels built without high memory support, kmap will not allow you
>to access memory beyond the normal physical memory boundary.

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

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.

methinks that i'm back to a modification of Timur's suggestion--
a bunch of manual page dir/table changes.

Any other suggestions or corrections to my comments?

thanks.

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

Re: temp. mem mappings

[Stephen C. Tweedie]

Hi,

On Wed, Jun 06, 2001 at 05:14:26PM -0400, cohutta wrote:

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

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

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

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

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

Re: temp. mem mappings

[cohutta]

> > > Allocate a virtual memory area using vmalloc and then save and
modify the
> > > pmd/pgd/pte to point to the physical memory you want.  To unmap,
just undo the
> > > previous steps.
> >
> > ioremap() is there for exactly that purpose.
>
> True, except that you can't use ioremap on normal memory, which is
what I
> assumed he was trying to do.

  Normal memory is identity-mapped very early in boot anyway (except for
  highmem on large Intel boxes, that is, and kmap() works for that.)
---

I don't really want to play with the page tables if i can help it.
I didn't use ioremap() because it's real system memory, not IO bus
memory.

How much normal memory is identity-mapped at boot on x86?
Is it more than 8 MB?

I'm trying to read some ACPI tables, like the FACP.
On my system, this is at physical address 0x3fffd7d7 (e.g.).

kmap() ends up calling set_pte(), which is close to what i am
already doing.  i'm having a problem on the unmap side when i
am done with the temporary mapping.

thanks.
/cohutta/

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

Re: temp. mem mappings

[Timur Tabi]

** Reply to message from cohutta <cohutta@MailAndNews.com> on Tue, 5 Jun 2001
16:42:52 -0400


> I don't really want to play with the page tables if i can help it.
> I didn't use ioremap() because it's real system memory, not IO bus
> memory.
> 
> How much normal memory is identity-mapped at boot on x86?
> Is it more than 8 MB?

Much more.  Somewhere between 2 and 4 GB is mapped.  Large memory support in
Linux has always confused me, so I can't remember exactly how much is mapped.

Keep in mind that if you want to access that memory as uncached or
write-combined, you'll need to use the method I described.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

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

Re: temp. mem mappings

[Joseph A. Knapka]

Timur Tabi wrote:
> 
> ** Reply to message from cohutta <cohutta@MailAndNews.com> on Tue, 5 Jun 2001
> 16:42:52 -0400
> 
> > I don't really want to play with the page tables if i can help it.
> > I didn't use ioremap() because it's real system memory, not IO bus
> > memory.
> >
> > How much normal memory is identity-mapped at boot on x86?
> > Is it more than 8 MB?
> 
> Much more.  Somewhere between 2 and 4 GB is mapped.  Large memory support in
> Linux has always confused me, so I can't remember exactly how much is mapped.

On x86, it's a little less than 1GB (4G-PAGE_OFFSET-<a little bit for
fixmaps,
kmap, vmalloc>); PAGE_OFFSET is 3GB by default. There is some stuff that
happens
before that mapping is done, though. All you can absolutely count on
when you
first enter 32-bit mode is the low 8MB. setup_arch() in
arch/i386/kernel/setup.c
is the place to look if you want to be sure; paging_init() is called
from there.

-- 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: temp. mem mappings

[Stephen C. Tweedie]

Hi,

On Tue, Jun 05, 2001 at 04:42:52PM -0400, cohutta wrote:

>   Normal memory is identity-mapped very early in boot anyway (except for
>   highmem on large Intel boxes, that is, and kmap() works for that.)
> 
> I don't really want to play with the page tables if i can help it.
> I didn't use ioremap() because it's real system memory, not IO bus
> memory.
> 
> How much normal memory is identity-mapped at boot on x86?
> Is it more than 8 MB?

> I'm trying to read some ACPI tables, like the FACP.
> On my system, this is at physical address 0x3fffd7d7 (e.g.).

It depends at what time during boot.  Some ACPI memory is reusable
once the system boots: the kernel parses the table then frees up the
memory which the BIOS initialised.

VERY early in boot, while the VM is still getting itself set up, there
is only a minimal mapping set up by the boot loader code.  However,
once the VM is initialised far enough to let you play with page
tables, all memory will be identity-mapped up to just below the 1GB
watermark.

> kmap() ends up calling set_pte(), which is close to what i am
> already doing.  i'm having a problem on the unmap side when i
> am done with the temporary mapping.

kunmap().  :-)  But kmap only works on CONFIG_HIGHMEM kernel builds.
On kernels built without high memory support, kmap will not allow you
to access memory beyond the normal physical memory boundary.

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

temp. mem mappings

[cohutta]

hi-

i'm trying to map some memory during kernel init.
(this is x86-specific.)
this should be temporary, unmapped after use.
this memory is not in the low identity-mapped 8 MB.

currently i have this sorta working by using a new fixed
mapping (linux/include/asm-i386/fixmap.h) and calling
set_fixmap() which calls set_pte_phys().
after i use (access, read-only) this memory, i try to
unmap it so that i can use the same virtual address
again by calling set_fixmap() again.
i use pte_clear() to unmap it.
however the next time that i call set_fixmap(),
set_pte_phys() gives me a pte_ERROR()...because the
pte hasn't been cleared (?).
but the new mapping seems to work.

i tried to make this similar to linux/include/asm-i386/highmem.h.

what is the a preferred/correct method to map and unmap memory
temporarily?

thanks.
/cohutta/

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

Re: temp. mem mappings

[Timur Tabi]

** Reply to message from cohutta <cohutta@MailAndNews.com> on Tue, 5 Jun 2001
13:54:15 -0400


> what is the a preferred/correct method to map and unmap memory
> temporarily?

Allocate a virtual memory area using vmalloc and then save and modify the
pmd/pgd/pte to point to the physical memory you want.  To unmap, just undo the
previous steps.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

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

Re: temp. mem mappings

[Stephen C. Tweedie]

Hi,

On Tue, Jun 05, 2001 at 01:25:27PM -0500, Timur Tabi wrote:
> ** Reply to message from cohutta <cohutta@MailAndNews.com> on Tue, 5 Jun 2001
> 13:54:15 -0400
> 
> > what is the a preferred/correct method to map and unmap memory
> > temporarily?
> 
> Allocate a virtual memory area using vmalloc and then save and modify the
> pmd/pgd/pte to point to the physical memory you want.  To unmap, just undo the
> previous steps.

ioremap() is there for exactly that purpose.  Playing with page
tables directly is most definitely frowned upon and is unlikely to
lead to portable code.  ioremap() will take a physical address and
return the new virtual address, and ioremap_nocache() additionally
specifies the memory as being uncachable (via page table flags) so
that it can be used for PCI control register remapping.

Both functions are declared in <asm/io.h> and are available on both
2.2 and 2.4.

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

Re: temp. mem mappings

[Timur Tabi]

** Reply to message from "Stephen C. Tweedie" <sct@redhat.com> on Tue, 5 Jun
2001 19:41:36 +0100


> > Allocate a virtual memory area using vmalloc and then save and modify the
> > pmd/pgd/pte to point to the physical memory you want.  To unmap, just undo the
> > previous steps.
> 
> ioremap() is there for exactly that purpose. 

True, except that you can't use ioremap on normal memory, which is what I
assumed he was trying to do.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

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

Re: temp. mem mappings

[Stephen C. Tweedie]

Hi,

On Tue, Jun 05, 2001 at 01:51:37PM -0500, Timur Tabi wrote:

> > > Allocate a virtual memory area using vmalloc and then save and modify the
> > > pmd/pgd/pte to point to the physical memory you want.  To unmap, just undo the
> > > previous steps.
> > 
> > ioremap() is there for exactly that purpose. 
> 
> True, except that you can't use ioremap on normal memory, which is what I
> assumed he was trying to do.

Normal memory is identity-mapped very early in boot anyway (except for
highmem on large Intel boxes, that is, and kmap() works for that.)

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/