Bigphysarea vs. kernel 2.4.32 and PPC405GPr

Bigphysarea vs. kernel 2.4.32 and PPC405GPr

[Stephen Williams]

I'm trying to use the bigphysarea patch to help me allocate big
physical chunks of memory for use by some custom embedded devices.
I've applied the bigphysarea-2.4.20 patch and built, no trouble,
and I've got it to config for my PPC. I can see at boot time that
the bigphysarea is getting its pages.

I'm trying to use a mmap call to the driver to map a chunk of this
memory into the process. The mmap for the driver has this:

      pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
      vma->vm_flags |= VM_RESERVED;

      npages = (vma->vm_end - vma->vm_start) / PAGE_SIZE;
      heap_map_base = bigphysarea_alloc_pages(npages, 1, GFP_KERNEL);

      printk("XXXX Map base=%p, %ld pages\n", heap_map_base, npages);

      rc = remap_page_range(vma->vm_start,
			    (unsigned long)heap_map_base,
			    npages*PAGE_SIZE,
			    vma->vm_page_prot);

The mmap returns without an error, but any access to the mapped
region gets me an immediate "Oops: machine check, sig: 7". I don't
see it. Where is the stupid mistake that I'm invariably making?


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re: Bigphysarea vs. kernel 2.4.32 and PPC405GPr

[Arno Geissel]

Try

      rc = remap_page_range(vma->vm_start,
 			    virt_to_phys(heap_map_base),
 			    npages*PAGE_SIZE,
 			    vma->vm_page_prot);

Arno

> I'm trying to use the bigphysarea patch to help me allocate big
> physical chunks of memory for use by some custom embedded devices.
> I've applied the bigphysarea-2.4.20 patch and built, no trouble,
> and I've got it to config for my PPC. I can see at boot time that
> the bigphysarea is getting its pages.
>
> I'm trying to use a mmap call to the driver to map a chunk of this
> memory into the process. The mmap for the driver has this:
>
>       pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
>       vma->vm_flags |= VM_RESERVED;
>
>       npages = (vma->vm_end - vma->vm_start) / PAGE_SIZE;
>       heap_map_base = bigphysarea_alloc_pages(npages, 1, GFP_KERNEL);
>
>       printk("XXXX Map base=%p, %ld pages\n", heap_map_base, npages);
>
>       rc = remap_page_range(vma->vm_start,
> 			    (unsigned long)heap_map_base,
> 			    npages*PAGE_SIZE,
> 			    vma->vm_page_prot);
>
> The mmap returns without an error, but any access to the mapped
> region gets me an immediate "Oops: machine check, sig: 7". I don't
> see it. Where is the stupid mistake that I'm invariably making?

Re: Bigphysarea vs. kernel 2.4.32 and PPC405GPr

[Stephen Williams]

That works nicely, thanks. I was under the mistaken impression that
the bigphysarea routines returned a physical address.

So now I can report that the bigphysarea patch works great on PPC
kernels 2.4.32+

Arno Geissel wrote:
> Try
> 
>       rc = remap_page_range(vma->vm_start,
>  			    virt_to_phys(heap_map_base),
>  			    npages*PAGE_SIZE,
>  			    vma->vm_page_prot);
> 
> Arno
> 
>> I'm trying to use the bigphysarea patch to help me allocate big
>> physical chunks of memory for use by some custom embedded devices.
>> I've applied the bigphysarea-2.4.20 patch and built, no trouble,
>> and I've got it to config for my PPC. I can see at boot time that
>> the bigphysarea is getting its pages.
>>
>> I'm trying to use a mmap call to the driver to map a chunk of this
>> memory into the process. The mmap for the driver has this:
>>
>>       pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
>>       vma->vm_flags |= VM_RESERVED;
>>
>>       npages = (vma->vm_end - vma->vm_start) / PAGE_SIZE;
>>       heap_map_base = bigphysarea_alloc_pages(npages, 1, GFP_KERNEL);
>>
>>       printk("XXXX Map base=%p, %ld pages\n", heap_map_base, npages);
>>
>>       rc = remap_page_range(vma->vm_start,
>> 			    (unsigned long)heap_map_base,
>> 			    npages*PAGE_SIZE,
>> 			    vma->vm_page_prot);
>>
>> The mmap returns without an error, but any access to the mapped
>> region gets me an immediate "Oops: machine check, sig: 7". I don't
>> see it. Where is the stupid mistake that I'm invariably making?


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."