public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: "David S. Miller" <davem@redhat.com>
Cc: reid.hekman@ndsu.nodak.edu, linux-kernel@vger.kernel.org,
	akpm@zip.com.au, alan@lxorg.ukuu.org
Subject: Re: Athlon PSE/AGP Bug
Date: Mon, 21 Jan 2002 17:54:10 +0100	[thread overview]
Message-ID: <20020121175410.G8292@athlon.random> (raw)
In-Reply-To: <1011610422.13864.24.camel@zeus> <20020121.053724.124970557.davem@redhat.com>
In-Reply-To: <20020121.053724.124970557.davem@redhat.com>; from davem@redhat.com on Mon, Jan 21, 2002 at 05:37:24AM -0800

On Mon, Jan 21, 2002 at 05:37:24AM -0800, David S. Miller wrote:
>    From: Reid Hekman <reid.hekman@ndsu.nodak.edu>
>    Date: 21 Jan 2002 04:53:39 -0600
>    
>    As I have a couple systems that may/may not be affected, I'm seeking
>    some clarification. Is this an effect of the errata published by AMD in
>    the Athlon models 4 & 6 revision guides as "INVLPG Instruction Does Not
>    Flush Entire Four-Megabyte Page Properly with Certain Linear Addresses"?
>    That errata lists all Athlon Thunderbirds as affected and all Athlon
>    Palominos except for stepping A5. 
>    
>    Regardless of specific errata listings, will future workarounds be
>    enabled based on cpuid or via a test for the bug itself?
> 
> The funny part is, if this published errata is the problem, it cannot
> be a problem under Linux since we never invalidate 4MB pages.  We
> create them at boot time and they never change after that.

correct, furthmore it cannot even trigger if you invlpg with an address
page aligned (4mbyte aligned in this case) like we would always do in
linux anyways, we never use invlpg on misaligned addresses, no matter if
the page is a 4M or a 4k page.  And I guess with PAE enabled it cannot
even trigger in first place (it speaks only about 4M pages, pae only
provides 2M pages instead).

I think this is a very very minor issue, I doubt anybody ever triggered
it in real life with linux.

And Gentoo is shipping a kernel with preempt and rmaps included, so it
can crash anytime anyways, no matter how good the cpu is, so if they
got crashes with such a kernel (maybe even with nvidia driver) that's
normal. I was speaking today with a trusted party doing vm benchmarking
and rmap crashes the kernel reproducibly under a stright calloc while
swapping heavily, so clearly the implementation is still broken. preempt
additionally will mess up all the locking into the nvidia driver as
well. so if the combination of the two runs for some time without any
lockup that's pure luck IMHO.

Andrea

  parent reply	other threads:[~2002-01-21 16:53 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-21 10:53 Athlon PSE/AGP Bug Reid Hekman
2002-01-21 13:37 ` David S. Miller
2002-01-21 13:50   ` Arjan van de Ven
2002-01-21 16:58     ` jepler
2002-01-21 17:26       ` Ed Sweetman
2002-01-21 22:14     ` David S. Miller
2002-01-21 16:54   ` Andrea Arcangeli [this message]
2002-01-21 17:57     ` Reid Hekman
2002-01-21 18:17     ` Andrew Morton
2002-01-21 19:11       ` Harold Campbell
2002-01-21 22:23       ` David S. Miller
2002-01-22  0:39         ` Andrea Arcangeli
2002-01-22  1:08           ` David S. Miller
2002-01-22  7:05             ` Ville Herva
2002-01-22  7:08               ` David S. Miller
2002-01-22  8:05                 ` Daniel Robbins
2002-01-22  0:26       ` Stuart Young
2002-01-22  0:36       ` Steve Brueggeman
2002-01-22  1:02         ` Steve Brueggeman
2002-01-22 20:13           ` Florian Weimer
2002-01-22 22:14             ` Ed Sweetman
2002-01-22 22:52               ` Steve Brueggeman
2002-01-22 23:49                 ` Rik van Riel
2002-01-23  0:36               ` Stuart Young
2002-01-23  1:20                 ` Rene Rebe
2002-01-23  2:01                   ` Gustavo Zacarias
2002-01-23  2:11                     ` Tom Hornyak
2002-01-22 22:32             ` Steve Brueggeman
2002-01-22  5:45         ` Shaya Potter
2002-01-22 12:58           ` Dave Jones
2002-01-22 15:27             ` Shaya Potter
2002-01-22 18:52               ` Greg
2002-01-22 22:08                 ` Rene Rebe
2002-01-21 22:19     ` David S. Miller
2002-01-22  0:37       ` Andrea Arcangeli
2002-01-22  0:43         ` Russell King
2002-01-22  0:53           ` Andrea Arcangeli
2002-01-22  0:55             ` Russell King
2002-01-22  1:07         ` David S. Miller
2002-01-22  1:27           ` Andrea Arcangeli
2002-01-22 16:57           ` David Woodhouse
2002-01-21 19:37 ` Alan Cox
2002-01-21 19:34   ` David Weinehall
2002-01-21 19:53     ` Sipos Ferenc
2002-01-22  6:32   ` Paul G. Allen
  -- strict thread matches above, loose matches on Subject: below --
2002-01-22 14:12 Halpaap, Mark (CETA)
2002-01-22 14:51 ` Ed Sweetman
2002-01-22 23:21   ` Ian Molton
2002-01-22 14:51 ` João Seabra
2002-01-23 18:49 ` Marek Mentel
2002-01-22 17:59 Ben Carrell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020121175410.G8292@athlon.random \
    --to=andrea@suse.de \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorg.ukuu.org \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reid.hekman@ndsu.nodak.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox