On Sun, 24 Dec 2006, Andrew Morton wrote:
>
> > I now _suspect_ that we're talking about something like
> >
> > - we started a writeout. The IO is still pending, and the page was
> >marked clean and is now in the "writeback" phase.
> > - a write happens to the page, and the page gets mar
On Sun, 24 Dec 2006 00:43:54 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I now _suspect_ that we're talking about something like
>
> - we started a writeout. The IO is still pending, and the page was
>marked clean and is now in the "writeback" phase.
> - a write happens to the
On Sun, 24 Dec 2006, Gordon Farquharson wrote:
>
> Is there any way to provide any debugging information that may help
> solve the problem ?
I think we have people working on this. I know I'm trying to even come up
with an idea of what is going on. I don't think we know yet.
> Would it help t
On 12/22/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-22 14:25]:
> > and it failed.
> Since you are on ARM you might want to try with the page_mkclean_one
> cleanup patch too.
I've already tried it and it didn't work. I just tried it again
On Fri, 2006-12-22 at 13:32 +0100, Martin Michlmayr wrote:
> * Andrei Popa <[EMAIL PROTECTED]> [2006-12-22 14:24]:
> > With all three patches I have corruption
>
> I've completed one installation with Linus' patch plus the two from
> Andrew successfully, but I'm currently trying again... but I
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-22 14:25]:
> > and it failed.
> Since you are on ARM you might want to try with the page_mkclean_one
> cleanup patch too.
I've already tried it and it didn't work. I just tried it again
together with Linus' patch and the two from Andrew and it st
On Fri, 22 Dec 2006, Peter Zijlstra wrote:
>
> fix page_mkclean_one()
>
> - add flush_cache_page() for all those virtual indexed cache
>architectures.
I think the flush_cache_page() should be after we've actually flushed it
from the TLB and re-inserted it (this is one reason why I did th
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-22 08:30]:
> Based on the kernel gurus current knowledge of the problem, would
> you expect the corruption to occur at the same point in a file, or
> is it possible that the corruption could occur at different points
> on successive Debian installer
On 12/22/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
... and now that we've completed this step, the apt cache has suddenly
been reduced (see Gordon's mail for an explanation) and it segfaults:
sh-3.1# ls -l /var/cache/apt/
total 12524
drwxr-xr-x 3 root root 12288 Dec 22 04:41 archives
-r
On Fri, Dec 22, 2006 at 01:32:49PM +0100, Martin Michlmayr wrote:
> * Andrei Popa <[EMAIL PROTECTED]> [2006-12-22 14:24]:
> > With all three patches I have corruption
>
> I've completed one installation with Linus' patch plus the two from
> Andrew successfully, but I'm currently trying again..
On 12/22/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
sh-3.1# ls -l /var/cache/apt/
total 5252
drwxr-xr-x 3 root root12288 Dec 22 04:41 archives
-rw-r--r-- 1 root root 12582912 Dec 22 04:45 pkgcache.bin
-rw-r--r-- 1 root root 8554 Dec 22 04:45 srcpkgcache.bin
This listing is a littl
On 12/21/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Andrew located at least one bug: we run cancel_dirty_page() too late in
"truncate_complete_page()", which means that do_invalidatepage() ends up
not clearing the page cache.
His patch is appended.
Thanks. I'll try this out later today.
A cleanup of try_to_unmap. I have not identified any races that this
would solve, but for consistencies sake.
Also includes a small s390 optimization by moving
page_test_and_clear_dirty() out of the vma iteration.
From: Peter Zijlstra <[EMAIL PROTECTED]>
We clear the page in the following sequ
On Fri, 2006-12-22 at 13:59 +0100, Martin Michlmayr wrote:
> * Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 13:32]:
> > I've completed one installation with Linus' patch plus the two from
> > Andrew successfully, but I'm currently trying again...
>
> and it failed.
Since you are on ARM y
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 13:32]:
> I've completed one installation with Linus' patch plus the two from
> Andrew successfully, but I'm currently trying again...
... and it failed.
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "u
* Andrei Popa <[EMAIL PROTECTED]> [2006-12-22 14:24]:
> With all three patches I have corruption
I've completed one installation with Linus' patch plus the two from
Andrew successfully, but I'm currently trying again... but I really
need a better testcase since an installation takes about an h
With all three patches I have corruption
diff --git a/fs/buffer.c b/fs/buffer.c
index d1f1b54..263f88e 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2834,7 +2834,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(
* Andrew Morton <[EMAIL PROTECTED]> [2006-12-22 02:17]:
> > This hunk (on top of git from about 2 days ago and your latest patch)
> > results in the installer hanging right at the start.
>
> You'll need this also:
It starts again, thanks.
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscri
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 11:10]:
> > immediately when I started wget, the hanging apt-get process
> > continued.
> ... and now that we've completed this step, the apt cache has suddenly
> been reduced (see Gordon's mail for an explanation) and it segfaults:
One of my ques
On Fri, 22 Dec 2006 11:00:04 +0100
Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> > - if (TestClearPageDirty(page) && account_size)
> > + if (TestClearPageDirty(page) && account_size) {
> > + dec_zone_page_state(page, NR_FILE_DIRTY);
> > task_io_account_cancelled_write(acc
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 11:06]:
> Okay, it's really weird. So apt-get just hangs doing nothing and I
> cannot even kill it. I just tried to download strace via wget and
> immediately when I started wget, the hanging apt-get process
> continued.
... and now that we've c
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 11:00]:
> This time, however, I let the installer continue and it seems that
> with your patch apt now works where it failed in the past, but it
> hangs later on. It's pretty weird because I cannot even kill the
> process:
Okay, it's really weird
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-21 21:20]:
> generating these files, pkgcache.bin grows to 12582912 bytes, and when
> apt-get finishes, pkgcache.bin is 6425533 bytes and srcpkgcache.bin is
> 64254483 bytes. This time, when apt-get exited, it had only created
> pkgcache.bin which w
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-21 20:54]:
> But it sounds like I probably misunderstood something, because I thought
> that Martin had acknowledged that this patch actually worked for him.
That's what I thought too but now I can confirm what Gordon sees. But
it's pretty weird. Our
On Thu, 21 Dec 2006, Gordon Farquharson wrote:
>
> I tested 2.6.19 with a version of Linus's patch that applies cleanly
> to 2.6.19 (patch appended to the end of this email) on ARM and apt-get
> failed. It did not segfault this time, but instead got stuck for about
> 20 to 30 minutes and was acc
On 12/21/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Can the call to task_io_account_cancelled_write() simply be removed
> from cancel_dirty_page() for testing the patch with 2.6.19 (since
> 2.6.19 doesn't seem to have the task I/O accounting) ?
Yes.
I tested 2.6.19 with a version of Linus
On Thu, 21 Dec 2006, Peter Zijlstra wrote:
>
> Also, I'm dubious about the while thing and stuck a WARN_ON(ret) thing
> at the beginning of the loop. flush_tlb_page() does IPI the other cpus
> to flush their tlb too, so there should not be a SMP race, Arjan?
Now, the reason I think the loop may
On Wed, 20 Dec 2006, Trond Myklebust wrote:
>
> I can't see that it is the business of invalidate_inode_pages2() to
> resolve races between ->direct_IO() and pages that are redirtied by
> mmap(). All it needs to ensure is that pages that clean are discarded,
> since those are neither consistent
On Thu, 21 Dec 2006, Andrei Popa wrote:
> On Wed, 2006-12-20 at 16:24 -0800, Linus Torvalds wrote:
> >
> > Martin, Peter, Andrei, pls give it a try. (Martin and Andrei may be
> > talking about different bugs, so _both_ of your experiences definitely
> > matter here).
>
> with http://lkml.org
On Wed, 2006-12-20 at 16:24 -0800, Linus Torvalds wrote:
>
> Btw, I'd really love to hear whether the patch I sent out actually _helps_
> at all, or whether we're just discussing something that in the end is just
> a cleanup..
>
> Martin, Peter, Andrei, pls give it a try. (Martin and Andrei may
On Thu, Dec 21, 2006 at 12:30:22PM +, Russell King wrote:
> On Wed, Dec 20, 2006 at 11:53:25PM -0800, Linus Torvalds wrote:
> > That's obviously a bug worth fixing on its own. Do you know when it
> > started?
>
> My last merge, just before 2.6.19-rc1.
Obviously 2.6.20-rc1.
--
Russell King
On Wed, Dec 20, 2006 at 11:53:25PM -0800, Linus Torvalds wrote:
> That's obviously a bug worth fixing on its own. Do you know when it
> started?
My last merge, just before 2.6.19-rc1.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscrib
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-20 11:50]:
> Martin, Andrei, does this make any difference for your corruption
> cases?
Works for me.
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
On Thu, Dec 21, 2006 at 09:18:45AM +0100, Martin Michlmayr wrote:
> * Russell King <[EMAIL PROTECTED]> [2006-12-20 22:11]:
> > > This patch doesn't fix my problem (apt segfaults on ARM because its
> > > database is corrupted).
> >
> > Are you using IDE in PIO mode? If so, the bug probably lies th
On Thu, 2006-12-21 at 10:20 +0100, Peter Zijlstra wrote:
> > Now you are flushing the tlb twice. ptep_clear_flush clears the pte and
> > flushes the tlb, ptep_establish sets the new pte and flushes the tlb.
> > Not good. Use set_pte_at instead of the ptep_establish.
>
> Yeah, sorry, I already noti
On Thu, 21 Dec 2006 02:17:05 -0700
"Gordon Farquharson" <[EMAIL PROTECTED]> wrote:
> Can the call to task_io_account_cancelled_write() simply be removed
> from cancel_dirty_page() for testing the patch with 2.6.19 (since
> 2.6.19 doesn't seem to have the task I/O accounting) ?
Yes.
-
To unsubscri
On Thu, 2006-12-21 at 10:16 +0100, Martin Schwidefsky wrote:
> On Thu, 2006-12-21 at 00:03 +0100, Peter Zijlstra wrote:
> > current version
>
> Nitpicking ..
>
> > @@ -444,17 +444,18 @@ static int page_mkclean_one(struct page
> > if (!pte)
> > goto out;
> >
> > - if (!pte_dirty
On 12/21/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
That said, I think the patch I sent out should actually work on top of
plain 2.6.19 too. I don't think things have changed in this area that
much. IOW, you don't _need_ latest -git to test it, you just need a broken
kernel ;)
I created a v
On Thu, 2006-12-21 at 00:03 +0100, Peter Zijlstra wrote:
> current version
Nitpicking ..
> @@ -444,17 +444,18 @@ static int page_mkclean_one(struct page
> if (!pte)
> goto out;
>
> - if (!pte_dirty(*pte) && !pte_write(*pte))
> - goto unlock;
> + while (pte
On Thu, 21 Dec 2006, Martin Michlmayr wrote:
>
> This is a known issue. The following patch has been proposed
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4030/1
> although I just notice that it has been marked as "discarded".
> Apparently Russell King commited a better patc
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-20 23:53]:
> > Unfortunately, I cannot get the latest git version of the kernel to
> > boot on the ARM machine on which Martin and I are experiencing the apt
> > segfault.
>
> Ouch.
>
> That's obviously a bug worth fixing on its own. Do you know when
* Russell King <[EMAIL PROTECTED]> [2006-12-20 22:11]:
> > This patch doesn't fix my problem (apt segfaults on ARM because its
> > database is corrupted).
>
> Are you using IDE in PIO mode? If so, the bug probably lies there.
I'm using usb-storage. It's used to access an external IDE drive in
a
On Wed, 2006-12-20 at 21:36 -0500, Trond Myklebust wrote:
> On Wed, 2006-12-20 at 23:15 +0100, Peter Zijlstra wrote:
> > I think this is also needed:
>
> NAK
>
> invalidate_inode_pages2() should _not_ be pretending that dirty pages
> are clean. This patch is incorrect both for the NFS usage and f
On Thu, 21 Dec 2006, Gordon Farquharson wrote:
>
> Unfortunately, I cannot get the latest git version of the kernel to
> boot on the ARM machine on which Martin and I are experiencing the apt
> segfault.
Ouch.
> After the kernel is finished uncompressing it prints "done,
> booting the kernel."
On 12/20/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Ok, I'll just put my money where my mouth is, and suggest a patch like
THIS instead.
Martin, Andrei, does this make any difference for your corruption cases?
Unfortunately, I cannot get the latest git version of the kernel to
boot on th
On Wed, 2006-12-20 at 15:55 -0800, Linus Torvalds wrote:
> > With your change I think what'll happen is that we'll correctly handle the
> > case where the page and its buffers are dirty (it gets left in place), but
> > we'll needlessy fail in the case where the page is dirty but the buffers
> > are
On Wed, 2006-12-20 at 23:15 +0100, Peter Zijlstra wrote:
> I think this is also needed:
NAK
invalidate_inode_pages2() should _not_ be pretending that dirty pages
are clean. This patch is incorrect both for the NFS usage and for the
directIO usage.
In the latter case, if someone has the page mmap
On Wed, Dec 20, 2006 at 03:55:25PM -0800, Linus Torvalds wrote:
> On Thu, 21 Dec 2006, David Chinner wrote:
> >
> > XFS appears to call clear_page_dirty to get the mapping tree dirty
> > tag set correctly at the same time the page dirty flag is cleared. I
> > note that this can be done by set_page
On Wed, 20 Dec 2006 16:43:31 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 20 Dec 2006, Linus Torvalds wrote:
> > >
> > > There's also redirty_page_for_writepage().
> >
> > _dirtying_ a page makes sense in any situation. You can always dirty them.
> > I'm just saying tha
On Wed, 20 Dec 2006, Linus Torvalds wrote:
> >
> > There's also redirty_page_for_writepage().
>
> _dirtying_ a page makes sense in any situation. You can always dirty them.
> I'm just saying that you can't just mark them *clean*.
>
> If your point was that the filesystem had better be able to
Btw, I'd really love to hear whether the patch I sent out actually _helps_
at all, or whether we're just discussing something that in the end is just
a cleanup..
Martin, Peter, Andrei, pls give it a try. (Martin and Andrei may be
talking about different bugs, so _both_ of your experiences def
On Wed, 20 Dec 2006, Andrew Morton wrote:
> >
> > So with my change, afaik, we will just return EIO to the invalidate, and
> > do the write.
>
> The write's already been done by this stage.
Ok, but the end result is the same: you MUST NOT just "cancel" a write. It
needs to be done, or the ba
On Wed, 20 Dec 2006 15:55:14 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > @@ -386,12 +399,8 @@ int invalidate_inode_pages2_range(struct
> > > address_space *mapping,
> >
> > invalidate_complete_page2() is pretty gruesome. We're handling the case
> > where someone went and redirti
On Thu, 21 Dec 2006, David Chinner wrote:
>
> XFS appears to call clear_page_dirty to get the mapping tree dirty
> tag set correctly at the same time the page dirty flag is cleared. I
> note that this can be done by set_page_writeback() if we clear the
> dirty flag on the page first when we are
On Wed, 20 Dec 2006, Andrew Morton wrote:
>
> > +void cancel_dirty_page(struct page *page, unsigned int account_size)
> > +{
> > + /* If we're cancelling the page, it had better not be mapped any more */
> > + if (page_mapped(page)) {
> > + static unsigned int warncount;
> > +
> >
On Wed, 20 Dec 2006 11:50:50 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Ok, I'll just put my money where my mouth is, and suggest a patch like
> THIS instead.
>
> ...
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index d1f1b54..263f88e 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
>
On Wed, Dec 20, 2006 at 11:50:50AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 20 Dec 2006, Linus Torvalds wrote:
> >
> > So that's why I've been harping on the fact that I think we simply do
> > really wrong things with PG_dirty at times [ ... ]
>
> Ok, I'll just put my money where my mouth is
On Wed, 2006-12-20 at 14:49 -0800, Linus Torvalds wrote:
>
> On Wed, 20 Dec 2006, Peter Zijlstra wrote:
> >
> > I think this is also needed:
>
> Yeah, that looks about right. Although I think it should go above the
> "try_to_release_page()", because right now we do that "ttrp()" with the
> dirt
On Wed, 2006-12-20 at 14:25 -0800, Linus Torvalds wrote:
>
> On Wed, 20 Dec 2006, Dave Kleikamp wrote:
> >
> > This patch removes some questionable code that attempted to make a
> > no-longer-used page easier to reclaim.
>
> If so, "cancel_dirty_page()" may actually be the right thing to use, but
On Wed, 20 Dec 2006, Peter Zijlstra wrote:
>
> I think this is also needed:
Yeah, that looks about right. Although I think it should go above the
"try_to_release_page()", because right now we do that "ttrp()" with the
dirty bit set, and we should let the low-level filesystem just know that
it
On Wed, 20 Dec 2006, Dave Kleikamp wrote:
>
> This patch removes some questionable code that attempted to make a
> no-longer-used page easier to reclaim.
If so, "cancel_dirty_page()" may actually be the right thing to use, but
only if you can guarantee that the page isn't mapped anywhere (and
On Wed, 2006-12-20 at 23:15 +0100, Peter Zijlstra wrote:
> I think this is also needed:
See also:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116603599904278&w=2
> ---
> mm/truncate.c |7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> Index: linux-2.6/mm/truncate.c
>
I think this is also needed:
---
mm/truncate.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
Index: linux-2.6/mm/truncate.c
===
--- linux-2.6.orig/mm/truncate.c
+++ linux-2.6/mm/truncate.c
@@ -320,19 +320,14 @@ inva
On Wed, Dec 20, 2006 at 06:03:23PM +0100, Martin Michlmayr wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-20 14:56]:
> > page_mkclean_one() fix
>
> This patch doesn't fix my problem (apt segfaults on ARM because its
> database is corrupted).
Are you using IDE in PIO mode? If so, the bug
On Wed, 2006-12-20 at 11:50 -0800, Linus Torvalds wrote:
> NOTE NOTE NOTE! I _only_ did enough to make things compile for my
> particular configuration. That means that right now the following
> filesystems are broken with this patch (because they use the totally
> broken old crap):
>
> CIF
On Wed, 2006-12-20 at 11:50 -0800, Linus Torvalds wrote:
> Nick, Hugh, Peter, Andrew? Comments?
Hooray! I'm all for this cleanup. Let us see where this road leads..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
On Wed, 20 Dec 2006, Linus Torvalds wrote:
>
> So that's why I've been harping on the fact that I think we simply do
> really wrong things with PG_dirty at times [ ... ]
Ok, I'll just put my money where my mouth is, and suggest a patch like
THIS instead.
This one clears up all the issues I f
On Wed, 20 Dec 2006, Martin Michlmayr wrote:
>
> > Anyway, the page_mkclean_one() fixes (along with _most_ things we've
> > looked at) shouldn't matter on UP, at least certainly not without
> > PREEMPT.
>
> Hmm. So what about UP without PREEMPT then...
So that's why I've been harping on the f
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-20 09:35]:
> Can you remind us:
> - your ARM is UP, right? Do you have PREEMPT on?
It's UP and PREEMPT is not set. I used 2.6.19 plus the patch that has
been posted.
> - This is probably a stupid question, but you did make sure that the
>databa
On Wed, 20 Dec 2006, Martin Michlmayr wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-20 14:56]:
> > page_mkclean_one() fix
>
> This patch doesn't fix my problem (apt segfaults on ARM because its
> database is corrupted).
Can you remind us:
- your ARM is UP, right? Do you have PREEMPT
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-20 14:56]:
> page_mkclean_one() fix
This patch doesn't fix my problem (apt segfaults on ARM because its
database is corrupted).
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Wed, 2006-12-20 at 12:26 +0100, Peter Zijlstra wrote:
> fix page_mkclean_one()
>
> it had several issues:
> - it failed to flush the cache
> - it failed to flush the tlb
> - it failed to do s390 (s390 guys, please verify this is now correct)
Sorry, page_mkclean is broken for s390. But it ha
On Wed, 2006-12-20 at 13:00 +, Hugh Dickins wrote:
> On Wed, 20 Dec 2006, Peter Zijlstra wrote:
> >
> > fix page_mkclean_one()
>
> Congratulations on getting to the bottom of it, Peter (if you have:
> I haven't digested enough of the thread to tell).
Well, I thought I understood, you just sh
On Wed, 20 Dec 2006, Peter Zijlstra wrote:
>
> fix page_mkclean_one()
Congratulations on getting to the bottom of it, Peter (if you have:
I haven't digested enough of the thread to tell). I'm mostly offline at
present, no time for dialogue, I'll throw out a few remarks and run...
>
> it had se
On 20/12/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Wed, 2006-12-20 at 12:39 +0100, Jesper Juhl wrote:
> Having the assignment of "ret = 1;" inside the loop seems a little
> pointless. Perhaps gcc can optimize it, but still, that assignment
> really only needs to happen once outside the loo
On Wed, 2006-12-20 at 12:39 +0100, Jesper Juhl wrote:
> On 20/12/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > fix page_mkclean_one()
> >
> > it had several issues:
> > - it failed to flush the cache
> > - it failed to flush the tlb
> > - it failed to do s390 (s390 guys, please verify th
On 20/12/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
fix page_mkclean_one()
it had several issues:
- it failed to flush the cache
- it failed to flush the tlb
- it failed to do s390 (s390 guys, please verify this is now correct)
Also, clear in a loop to ensure SMP safeness as suggested by
101 - 177 of 177 matches
Mail list logo
