[BUGFIX]{PATCH] flush icache on ia64 take2

This is a patch for fixing icache flush race in ia64(Montecito) by implementing flush_icache_page() at el. Changelog: - updated against 2.6.22-rc7 (previous one was against 2.6.21) - removed hugetlbe's lazy_mmu_prot_update(). - rewrote patch description. - removed patch against mprotect() if f

Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.

On Fri, 6 Jul 2007 07:18:53 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > On Thu, 5 Jul 2007 12:13:09 -0600 > Mike Stroyan <[EMAIL PROTECTED]> wrote: > > The L3 cache is involved in the HP-UX defect description because the > > earlier HP-UX patch PHKL_33781 added flushing of the instructi

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

On Thu, Jul 05, 2007 at 10:57:00AM +0200, Zoltan Menyhart wrote: > KAMEZAWA Hiroyuki wrote: > >In our test, we confirmed that this can be fixed by flushing L2I just > >before SetPageUptodate() in NFS. > > I can agree. > We can be more permissive: it can be done anywhere after the new > data is pu

Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.

On Thu, 5 Jul 2007 12:13:09 -0600 Mike Stroyan <[EMAIL PROTECTED]> wrote: > You don't seem to have removed the lazy_mmu_prot_update() calls from > mm/hugetlb.c. Will that build with HUGETLBFS configured? > Thanks, it's my patch refresh miss... Sigh.. -Kame - To unsubscribe from this list: send

Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.

On Thu, 5 Jul 2007 12:13:09 -0600 Mike Stroyan <[EMAIL PROTECTED]> wrote: > The L3 cache is involved in the HP-UX defect description because the > earlier HP-UX patch PHKL_33781 added flushing of the instruction cache > when an executable mapping was removed. Linux never added that > unsuccessfu

Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.

On Wed, Jul 04, 2007 at 03:05:04PM +0900, KAMEZAWA Hiroyuki wrote: > This is a experimental patch for fixing icache flush race of ia64(Montecito). > > Problem Description: > Montecito, new ia64 processor, has separated L2 i-cache and d-cache, > and i-cache and d-cache is not consistent in automati

Re: [IA64] [kdump] machveg=dig on hpzx1 platforms

Here is a patch to do that. We use this internally, but I had forgotten to post it. Not that it matters a huge amount, but this has been in RHEL5 for sometime and does fix the "machvec=dig" nuisance. (Sorry for not replying earlier Terry -- I had a huge backlog of things to get to befor

Re: [RFC][PATCH take2 0/13] Support vector domain on ia64

Hi Tony, Luck, Tony wrote: >> Here is a series of patches for ia64 vector domain. By these patches, we can >> use more than 256 irqs. The patchset is based on existing x86-64 vector >> domain >> code. This is for 2.6.22-rc5 and I tested them on my ia64 box. > > There are a few whitespace issues

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

KAMEZAWA Hiroyuki wrote: On Wed, 04 Jul 2007 16:24:38 +0200 Zoltan Menyhart <[EMAIL PROTECTED]> wrote: Machines star up whit bit 5 = 0, reading instruction pages via NFS has to flush them from L2I. In our test, we confirmed that this can be fixed by flushing L2I just before SetPageUptodate(

Re: [RFC][PATCH] fsys_gettimeofday leaps days if it runs with nojitter

Andreas Schwab wrote: Hidetoshi Seto <[EMAIL PROTECTED]> writes: Index: linux-2.6.21/arch/ia64/kernel/fsys.S === --- linux-2.6.21.orig/arch/ia64/kernel/fsys.S +++ linux-2.6.21/arch/ia64/kernel/fsys.S @@ -247,6 +247,9 @@ .time_red

Re: [RFC][PATCH] fsys_gettimeofday leaps days if it runs with nojitter

Hidetoshi Seto <[EMAIL PROTECTED]> writes: > I suspected the value of r28. > So I just relocate "consuming" of r28 to early stage. > > >> Index: linux-2.6.21/arch/ia64/kernel/fsys.S >> === >> --- linux-2.6.21.orig/arch/ia64/kernel/fs

[RFC][PATCH] fsys_gettimeofday leaps days if it runs with nojitter

Hi all, I have run a test of gettimeofday() with "nojitter" option to make sure whether time fluctuating is really there or not. > $ dmesg | grep ITC > Jitter checking for ITC timers disabled > CPU 0: base freq=200.000MHz, ITC ratio=15/2, ITC freq=1500.000MHz > CPU 1: synchronized ITC with CPU 0