Prev: usb device descriptor read/64, error -110
Next: Add IDE mode support for SB600 SATA
From: Jiri Slaby on 31 Oct 2006 12:00
Guillermo Marcus wrote:
> Hi Jiri,
>
> The fact that it does not works with RAM is well documented in LDD3,
> pages 430++. It says (and I tested) that remap_xxx_range does not work
> in this case. They suggest a method using nopage, similar to the one I
> implement.

Could somebody confirm, that this still holds?

> I do not see why remap_xxx_range has the limitation, but it is there.
> The question is then: can the limitation be removed, or can we implement
> a new function that maps RAM all at once without the need for a nopage
> implementation?
>
> In any case, here is the code.

Hmm, interesting. I used remap_pfn_range for this purpose today and it worked (I
double-checked this). I should probably do the rework :(.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Franck Bui-Huu on 31 Oct 2006 12:10
Hi,

Jiri Slaby wrote:
> Guillermo Marcus wrote:
>> Hi Jiri,
>>
>> The fact that it does not works with RAM is well documented in LDD3,
>> pages 430++. It says (and I tested) that remap_xxx_range does not work
>> in this case. They suggest a method using nopage, similar to the one I
>> implement.
>
> Could somebody confirm, that this still holds?

Apparently this restriction has been removed since 2.6.15 when
VM_PFNMAP flag has been introduced, see commit
6aab341e0a28aff100a09831c5300a2994b8b986

Why there's such restriction before 2.6.15, I haven't searched
yet, but any hints would be appreciated.

Thanks
Franck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Russell King on 31 Oct 2006 14:30
On Tue, Oct 31, 2006 at 05:00:59PM +0100, Jiri Slaby wrote:
> Piece of code please. pci_alloc_consistent calls __get_free_pages, and there
> should be no problem with mmaping this area.

That is an implementation detail which is not portable to other
architectures. Please don't encourage people to use non-portable
implementation details.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 31 Oct 2006 14:40
Russell King wrote:
> On Tue, Oct 31, 2006 at 05:00:59PM +0100, Jiri Slaby wrote:
>> Piece of code please. pci_alloc_consistent calls __get_free_pages, and there
>> should be no problem with mmaping this area.
>
> That is an implementation detail which is not portable to other
> architectures. Please don't encourage people to use non-portable
> implementation details.

Sorry, I stand corrected, thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Miguel Ojeda on 31 Oct 2006 14:50
On 10/31/06, Jiri Slaby <jirislaby(a)gmail.com> wrote:
> Guillermo Marcus wrote:
> > Hi Jiri,
> >
> > The fact that it does not works with RAM is well documented in LDD3,
> > pages 430++. It says (and I tested) that remap_xxx_range does not work
> > in this case. They suggest a method using nopage, similar to the one I
> > implement.
>
> Could somebody confirm, that this still holds?
>

Hum, I also tried it some days ago and it didn't work for me, so I
read LDD3 and I found such explanation about such limitation of
remap_pfn_range(). I heard then that changed in 2.6.15 because of the
new flag; so I have had the same situation.

If it is possible to remap a kernel buffer to userspace with
remap_pfn_range, how should be done the right way?

> > I do not see why remap_xxx_range has the limitation, but it is there.
> > The question is then: can the limitation be removed, or can we implement
> > a new function that maps RAM all at once without the need for a nopage
> > implementation?
> >
> > In any case, here is the code.
>
> Hmm, interesting. I used remap_pfn_range for this purpose today and it worked (I
> double-checked this). I should probably do the rework :(.
>
> regards,
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: usb device descriptor read/64, error -110
Next: Add IDE mode support for SB600 SATA