> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> Jes Sorensen <[EMAIL PROTECTED]> wrote:
>> Convert /dev/mem read/write calls to use arch_translate_mem_ptr if
>> available. Needed on ia64 for pages converted fo uncached mappings
>> to avoid it being accessed in cached mode
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew Jes Sorensen [EMAIL PROTECTED] wrote:
Convert /dev/mem read/write calls to use arch_translate_mem_ptr if
available. Needed on ia64 for pages converted fo uncached mappings
to avoid it being accessed in cached mode after the conversion
Jes Sorensen <[EMAIL PROTECTED]> wrote:
>
> Convert /dev/mem read/write calls to use arch_translate_mem_ptr if
> available. Needed on ia64 for pages converted fo uncached mappings to
> avoid it being accessed in cached mode after the conversion which can
> lead to memory corruption. Introduces
Jes Sorensen [EMAIL PROTECTED] wrote:
Convert /dev/mem read/write calls to use arch_translate_mem_ptr if
available. Needed on ia64 for pages converted fo uncached mappings to
avoid it being accessed in cached mode after the conversion which can
lead to memory corruption. Introduces
> "Jes" == Jes Sorensen <[EMAIL PROTECTED]> writes:
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> This patch causes hiccups on my ia32e box.
Andrew> linux:/home/akpm# /usr/sbin/hwscan --isapnp zsh: 7528
Andrew> segmentation fault
Jes> Weird, I'll take a look.
Jes == Jes Sorensen [EMAIL PROTECTED] writes:
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew This patch causes hiccups on my ia32e box.
Andrew linux:/home/akpm# /usr/sbin/hwscan --isapnp zsh: 7528
Andrew segmentation fault
Jes Weird, I'll take a look.
-EPROGRAMMERISANIDIOT ... try
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> [EMAIL PROTECTED] (Jes Sorensen) wrote:
>> This patch introduces ia64 specific read/write handlers for
>> /dev/mem access which is needed to avoid uncached pages to be
>> accessed through the cached kernel window which can lead
[EMAIL PROTECTED] (Jes Sorensen) wrote:
>
> This patch introduces ia64 specific read/write handlers for /dev/mem
> access which is needed to avoid uncached pages to be accessed through
> the cached kernel window which can lead to random corruption.
This patch causes hiccups on my ia32e box.
[EMAIL PROTECTED] (Jes Sorensen) wrote:
This patch introduces ia64 specific read/write handlers for /dev/mem
access which is needed to avoid uncached pages to be accessed through
the cached kernel window which can lead to random corruption.
This patch causes hiccups on my ia32e box.
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew [EMAIL PROTECTED] (Jes Sorensen) wrote:
This patch introduces ia64 specific read/write handlers for
/dev/mem access which is needed to avoid uncached pages to be
accessed through the cached kernel window which can lead to random
> "Christoph" == Christoph Hellwig <[EMAIL PROTECTED]> writes:
Christoph> Please remove the ifdef by letting every architecture
Christoph> implement a arch_translate_mem_ptr (and give it a saner
Christoph> name while you're at it).
Ok, I thought it was tidier the other way, but I am not
Christoph == Christoph Hellwig [EMAIL PROTECTED] writes:
Christoph Please remove the ifdef by letting every architecture
Christoph implement a arch_translate_mem_ptr (and give it a saner
Christoph name while you're at it).
Ok, I thought it was tidier the other way, but I am not biased.
> + page = pfn_to_page(p >> PAGE_SHIFT);
> + /*
> + * On ia64 if a page has been mapped somewhere as
> + * uncached, then it must also be accessed uncached
> + * by the kernel or data corruption may occur
> + */
> +#ifdef
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> Jes Sorensen <[EMAIL PROTECTED]> wrote:
>> After applying the clue 2x4 to my head a couple of times, I came
>> up with this patch. Hopefully it will work a bit better ;-)
>>
Andrew> I know it's repetitious, but it's nice to
> However what happens if someone wants to share say some
> texture ram between the kernel and a video card and that has to be
> mapped uncached? Though up example here though.
also that's surely supposed to be controlled by some kernel driver,
which in turn can and should export it's own mmap
> "Arjan" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
Arjan> On Tue, 2005-02-22 at 17:30 -0500, Jes Sorensen wrote:
>> For userspace it's used by some of the MPI type apps in userland.
Arjan> you got to be kidding. Why are these MPI apps accessing memory
Arjan> that the kernel has
Arjan == Arjan van de Ven [EMAIL PROTECTED] writes:
Arjan On Tue, 2005-02-22 at 17:30 -0500, Jes Sorensen wrote:
For userspace it's used by some of the MPI type apps in userland.
Arjan you got to be kidding. Why are these MPI apps accessing memory
Arjan that the kernel has mapped cached (eg
However what happens if someone wants to share say some
texture ram between the kernel and a video card and that has to be
mapped uncached? Though up example here though.
also that's surely supposed to be controlled by some kernel driver,
which in turn can and should export it's own mmap
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew Jes Sorensen [EMAIL PROTECTED] wrote:
After applying the clue 2x4 to my head a couple of times, I came
up with this patch. Hopefully it will work a bit better ;-)
Andrew I know it's repetitious, but it's nice to maintain a changelog
+ page = pfn_to_page(p PAGE_SHIFT);
+ /*
+ * On ia64 if a page has been mapped somewhere as
+ * uncached, then it must also be accessed uncached
+ * by the kernel or data corruption may occur
+ */
+#ifdef
On Tue, 2005-02-22 at 16:38 -0500, Jes Sorensen wrote:
> > "Dave" == Dave Hansen <[EMAIL PROTECTED]> writes:
>
> Dave> I was talking with Nigel Cunningham about doing something a
> Dave> little different from the classic page flag bits when the number
> Dave> of users is restricted and
Jes Sorensen <[EMAIL PROTECTED]> wrote:
>
> After applying the clue 2x4 to my head a couple of times, I came up
> with this patch. Hopefully it will work a bit better ;-)
>
I know it's repetitious, but it's nice to maintain a changelog entry along
with the patch. Especially when seventy people
On Tue, 2005-02-22 at 17:30 -0500, Jes Sorensen wrote:
>
> For userspace it's used by some of the MPI type apps in userland.
you got to be kidding. Why are these MPI apps accessing memory that the
kernel has mapped cached (eg ram) via /dev/mem?
(eg my proposal is to make /dev/mem to be just
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
>> > >> + if (page->flags & PG_uncached)
>> >
>> > Andrew> dude. That ain't gonna work ;)
>> >
>> > Pardon my lack
> "Arjan" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
Arjan> On Tue, 2005-02-22 at 04:52 -0500, Jes Sorensen wrote:
>> Hi,
>>
>> This patch introduces ia64 specific read/write handlers for
>> /dev/mem access which is needed to avoid uncached pages to be
>> accessed through the cached
On Tue, 2005-02-22 at 04:52 -0500, Jes Sorensen wrote:
> Hi,
>
> This patch introduces ia64 specific read/write handlers for /dev/mem
> access which is needed to avoid uncached pages to be accessed through
> the cached kernel window which can lead to random corruption. It also
> introduces a new
> "Dave" == Dave Hansen <[EMAIL PROTECTED]> writes:
Dave> I was talking with Nigel Cunningham about doing something a
Dave> little different from the classic page flag bits when the number
Dave> of users is restricted and performance isn't ultra-critical.
Dave> Would something like this work
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
>> > >> + if (page->flags & PG_uncached)
>> >
>> > Andrew> dude. That ain't gonna work ;)
>> >
>> > Pardon my lack
I was talking with Nigel Cunningham about doing something a little
different from the classic page flag bits when the number of users is
restricted and performance isn't ultra-critical. Would something like
this work for you, instead of using a real page->flags bit for
PG_cached?
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
> > >> + if (page->flags & PG_uncached)
> >
> > Andrew> dude. That ain't gonna work ;)
> >
> > Pardon my lack of clue, but why not?
if (page->flags & (1< I think you're
>On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
>> >> + if (page->flags & PG_uncached)
>>
>> Andrew> dude. That ain't gonna work ;)
>>
>> Pardon my lack of clue, but why not?
>
>I think you're supposed to always use test_bit() to check page flags
You defined PG_uncached as "20"
On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
> >> + if (page->flags & PG_uncached)
>
> Andrew> dude. That ain't gonna work ;)
>
> Pardon my lack of clue, but why not?
I think you're supposed to always use test_bit() to check page flags
--
"Next the statesmen will invent
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> [EMAIL PROTECTED] (Jes Sorensen) wrote:
>> Hi,
>>
>> This patch introduces ia64 specific read/write handlers for
>> /dev/mem access which is needed to avoid uncached pages to be
>> accessed through the cached kernel window
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> Is it possible to avoid consuming a page flag?
>
> If this is an ia64-only (or 64-bit-only) thing I guess we could use bit 32.
It's not. i386 essentially has the same problem. Other architectures
likely too. We definitely need a generic solution,
[EMAIL PROTECTED] (Jes Sorensen) wrote:
>
> Hi,
>
> This patch introduces ia64 specific read/write handlers for /dev/mem
> access which is needed to avoid uncached pages to be accessed through
> the cached kernel window which can lead to random corruption. It also
> introduces a new page-flag
Hi,
This patch introduces ia64 specific read/write handlers for /dev/mem
access which is needed to avoid uncached pages to be accessed through
the cached kernel window which can lead to random corruption. It also
introduces a new page-flag PG_uncached which will be used to mark the
uncached
Hi,
This patch introduces ia64 specific read/write handlers for /dev/mem
access which is needed to avoid uncached pages to be accessed through
the cached kernel window which can lead to random corruption. It also
introduces a new page-flag PG_uncached which will be used to mark the
uncached
[EMAIL PROTECTED] (Jes Sorensen) wrote:
Hi,
This patch introduces ia64 specific read/write handlers for /dev/mem
access which is needed to avoid uncached pages to be accessed through
the cached kernel window which can lead to random corruption. It also
introduces a new page-flag
Andrew Morton [EMAIL PROTECTED] writes:
Is it possible to avoid consuming a page flag?
If this is an ia64-only (or 64-bit-only) thing I guess we could use bit 32.
It's not. i386 essentially has the same problem. Other architectures
likely too. We definitely need a generic solution, especially
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew [EMAIL PROTECTED] (Jes Sorensen) wrote:
Hi,
This patch introduces ia64 specific read/write handlers for
/dev/mem access which is needed to avoid uncached pages to be
accessed through the cached kernel window which can lead to random
On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
+ if (page-flags PG_uncached)
Andrew dude. That ain't gonna work ;)
Pardon my lack of clue, but why not?
I think you're supposed to always use test_bit() to check page flags
--
Next the statesmen will invent cheap lies,
On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
+ if (page-flags PG_uncached)
Andrew dude. That ain't gonna work ;)
Pardon my lack of clue, but why not?
I think you're supposed to always use test_bit() to check page flags
You defined PG_uncached as 20 ... so either:
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
+ if (page-flags PG_uncached)
Andrew dude. That ain't gonna work ;)
Pardon my lack of clue, but why not?
if (page-flags (1PG_uncached))
would have been correcter.
I was talking with Nigel Cunningham about doing something a little
different from the classic page flag bits when the number of users is
restricted and performance isn't ultra-critical. Would something like
this work for you, instead of using a real page-flags bit for
PG_cached?
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew Matthew Wilcox [EMAIL PROTECTED] wrote:
On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
+ if (page-flags PG_uncached)
Andrew dude. That ain't gonna work ;)
Pardon my lack of clue, but why not?
Andrew
Dave == Dave Hansen [EMAIL PROTECTED] writes:
Dave I was talking with Nigel Cunningham about doing something a
Dave little different from the classic page flag bits when the number
Dave of users is restricted and performance isn't ultra-critical.
Dave Would something like this work for you,
On Tue, 2005-02-22 at 04:52 -0500, Jes Sorensen wrote:
Hi,
This patch introduces ia64 specific read/write handlers for /dev/mem
access which is needed to avoid uncached pages to be accessed through
the cached kernel window which can lead to random corruption. It also
introduces a new
Arjan == Arjan van de Ven [EMAIL PROTECTED] writes:
Arjan On Tue, 2005-02-22 at 04:52 -0500, Jes Sorensen wrote:
Hi,
This patch introduces ia64 specific read/write handlers for
/dev/mem access which is needed to avoid uncached pages to be
accessed through the cached kernel window which can
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew Matthew Wilcox [EMAIL PROTECTED] wrote:
On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
+ if (page-flags PG_uncached)
Andrew dude. That ain't gonna work ;)
Pardon my lack of clue, but why not?
Andrew
On Tue, 2005-02-22 at 17:30 -0500, Jes Sorensen wrote:
For userspace it's used by some of the MPI type apps in userland.
you got to be kidding. Why are these MPI apps accessing memory that the
kernel has mapped cached (eg ram) via /dev/mem?
(eg my proposal is to make /dev/mem to be just
Jes Sorensen [EMAIL PROTECTED] wrote:
After applying the clue 2x4 to my head a couple of times, I came up
with this patch. Hopefully it will work a bit better ;-)
I know it's repetitious, but it's nice to maintain a changelog entry along
with the patch. Especially when seventy people have
On Tue, 2005-02-22 at 16:38 -0500, Jes Sorensen wrote:
Dave == Dave Hansen [EMAIL PROTECTED] writes:
Dave I was talking with Nigel Cunningham about doing something a
Dave little different from the classic page flag bits when the number
Dave of users is restricted and performance isn't
52 matches
Mail list logo
