Russell King <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 01, 2005 at 05:54:33PM +0100, Catalin Marinas wrote:
>> I haven't checked the original patch but it might work (by luck)
>> without the I-cache invalidation (and without stressing it too
>> much). This is because you might do a full mm flush whe
On Mon, Aug 01, 2005 at 05:54:33PM +0100, Catalin Marinas wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> > On Mon, Aug 01, 2005 at 01:24:04PM +0100, Catalin Marinas wrote:
> >> "David S. Miller" <[EMAIL PROTECTED]> wrote:
> >> > If one cpu stores, does it get picked up in the other cpu's I-cach
Russell King <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 01, 2005 at 01:24:04PM +0100, Catalin Marinas wrote:
>> "David S. Miller" <[EMAIL PROTECTED]> wrote:
>> > If one cpu stores, does it get picked up in the other cpu's I-cache?
>>
>> It only gets picked up by the other CPU's D-cache (which is ful
On Mon, Aug 01, 2005 at 01:24:04PM +0100, Catalin Marinas wrote:
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
> > From: Russell King <[EMAIL PROTECTED]>
> > Date: Fri, 29 Jul 2005 16:13:43 +0100
> >
> >> My current patch to get this working is below. The only thing which
> >> really seems to fix
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> The "lazy dcache flushing" he mentioned only flushes on the
> processor where the store occurred, not on any other cpus.
>
> He took the sparc64 code which, at the time of the flush_dcache_page()
> call, stores the current cpu number in the page->flags
From: Catalin Marinas <[EMAIL PROTECTED]>
Date: Mon, 01 Aug 2005 13:24:04 +0100
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
> > If not, you cannot use the lazy dcache flushing method, and in fact
> > you must broadcast the flush on all processors.
>
> Why wouldn't the lazy dcache flushing meth
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Russell King <[EMAIL PROTECTED]>
> Date: Fri, 29 Jul 2005 16:13:43 +0100
>
>> My current patch to get this working is below. The only thing which
>> really seems to fix the issue is the __flush_dcache_page call in
>> read_pages() - if I remove t
From: Russell King <[EMAIL PROTECTED]>
Date: Sat, 30 Jul 2005 21:08:07 +0100
> Thanks David.
No problem. An interesting tidbit would be whether the
system is stable, without your patch you posted, in pure
uniprocessor mode with these cpus.
-
To unsubscribe from this list: send the line "unsubscr
On Sat, Jul 30, 2005 at 12:40:52PM -0700, David S. Miller wrote:
> From: Russell King <[EMAIL PROTECTED]>
> > My current patch to get this working is below. The only thing which
> > really seems to fix the issue is the __flush_dcache_page call in
> > read_pages() - if I remove this, I get spurious
From: Russell King <[EMAIL PROTECTED]>
Date: Fri, 29 Jul 2005 16:13:43 +0100
> My current patch to get this working is below. The only thing which
> really seems to fix the issue is the __flush_dcache_page call in
> read_pages() - if I remove this, I get spurious segfaults and illegal
> instructi
Hi,
I've been trying for the last 4 or 5 days to get the kernel stable on
an ARM SMP platform. This platform has harvard PIPT caches with no
aliasing issues inside the separate I/D caches, except for the lack
of snooping between the I and D cache. The caches are in write allocate
mode.
This mea
11 matches
Mail list logo
