public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Dan Hollis <goemon@anime.net>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	<linux-kernel@vger.kernel.org>,
	ebiederm@xmission.com
Subject: Re: [PATCH] Athlon bug stomper. Pls apply.
Date: Thu, 20 Sep 2001 13:08:25 MET-1	[thread overview]
Message-ID: <3FD9CFB2E5A@vcnet.vc.cvut.cz> (raw)

On 19 Sep 01 at 15:13, Dan Hollis wrote:
> On 19 Sep 2001, Eric W. Biederman wrote:
> > Of course VIA looking at what they have done and what that bit is
> > supposed to be is easiest as they have the schemantics of those
> > chips.  But there is not reason to be limited to just that approach.

Well, I want to add some confusion into this thread...
 
> We definitely need more data points too. So far we dont have any athlon.c
> data for kt133a with the bit on and off, only kt133.

... I have at home Asus A7V (with KT133, non A), it has register 0x55
set to 0x89 and I thought that it works fine. I modified athlon.c
so that it fills buffer with random data on start, and then it compares
results of copy_page. And after about 10th run with 0x89 promise
driver told me that func:13 (not 14...) is not supported and all HDDs
became inaccessible. After reboot portion of /usr/include/bits (and 
few other) was overwritten with 0xFF... I was not able to recreate 
this problem after that crash (but I did not tried too hard, as I have
important data on my hdds, and all hdds attached to promise were
affected, not only one which was 'active' before crash (I was doing
compilation & logged outputs on secondary master, but primary master
was corrupted...)

After fsck, reinstalling libc6-dev and apache-doc, I started playing
with 0x55 bits and found that bits 0x80 and 0x01 have no effect on
performance, but CLEARING bit 0x08 increases my motherboard performace
by 1% (I'm getting very consistent results, they vary around +-10 cycles,
with 12200 cycles with 0x08 and 12060 with 0x00 in register 0x55).

So I personally will apply this patch even on my KT133... And just
for completness, kernel 2.4.9-ac10 (with AMD opts), Athlon 1GHz, two
singlesided 128MB DIMMs, interleaving enabled (disabling slows down
K7 copy page system by 4%).
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

             reply	other threads:[~2001-09-20 11:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-20 13:08 Petr Vandrovec [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-09-19 23:33 [PATCH] Athlon bug stomper. Pls apply Leif Sawyer
2001-09-19 21:15 Petr Vandrovec
2001-09-19 19:21 ` Arjan van de Ven
2001-09-19 19:51   ` Dan Hollis
2001-09-19 19:59     ` Arjan van de Ven
2001-09-19 21:44     ` Eric W. Biederman
2001-09-19 22:13       ` Dan Hollis
2001-09-19 22:49         ` John Alvord
2001-09-19 23:14           ` Dan Hollis
2001-09-19 23:32             ` Daniel T. Chen
2001-09-19 22:55         ` Roberto Jung Drebes
2001-09-21 17:22     ` bill davidsen
2001-09-21 19:13       ` Dan Hollis
2001-09-19 20:52 ` Vojtech Pavlik
2001-09-19 14:31 Re[2]: " Liakakis Kostas
2001-09-19 14:43 ` Stefan Smietanowski
2001-09-19 13:47 Re[2]: " Thomas Langås
2001-09-19 14:55 ` Jan Niehusmann
2001-09-19 16:00   ` Linus Torvalds
2001-09-19 17:15     ` safemode
2001-09-19 18:22       ` Stefan Smietanowski
2001-09-19 18:43     ` Re[2]: " Dan Hollis
2001-09-19 18:55       ` Arjan van de Ven
2001-09-19 19:00         ` Roberto Jung Drebes
2001-09-19 19:17           ` Arjan van de Ven
2001-09-19 20:16           ` Dan Hollis
2001-09-19 19:50         ` Ignacio Vazquez-Abrams
2001-09-19 20:01           ` Ignacio Vazquez-Abrams
2001-09-19 20:40             ` Ignacio Vazquez-Abrams
2001-09-19 21:43               ` safemode
2001-09-19 22:22                 ` Brad Pepers
2001-09-19 22:28                   ` Erno Kuusela
2001-09-19 20:36         ` Simen Thoresen
2001-09-19 20:37           ` Dan Hollis
2001-09-19 20:51             ` Simen Thoresen
2001-09-19 23:00               ` Roberto Jung Drebes
2001-09-19 20:36         ` Vojtech Pavlik
2001-09-19 20:57           ` Dan Hollis
2001-09-19 21:29             ` Vojtech Pavlik
2001-09-19 23:23         ` Luigi Genoni
2001-09-20  9:03         ` VDA
2001-09-20  0:19     ` Re[2]: " Nicholas Knight
2001-09-20  1:27       ` Stefan Smietanowski
2001-09-18 14:51 VDA
2001-09-18 15:43 ` Alan Cox
2001-09-20  4:56   ` Albert D. Cahalan
2001-09-18 17:45 ` Jeff Garzik
2001-09-18 21:39 ` Liakakis Kostas
2001-09-23 23:33 ` Jan Niehusmann
2001-09-24 15:44   ` bill davidsen

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=3FD9CFB2E5A@vcnet.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=arjanv@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=goemon@anime.net \
    --cc=linux-kernel@vger.kernel.org \
    /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