public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gerard Sharp <gsharp@ihug.co.nz>
To: linux-kernel@vger.kernel.org
Subject: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
Date: Sat, 09 Dec 2000 22:43:37 +1300	[thread overview]
Message-ID: <3A31FEC9.B824E695@ihug.co.nz> (raw)

Hello again

I have performed some tests; and reached the following conclusions
regarding this matter.
As always, UniProcessor kernels have no problems; only SMP ones.

kernel 2.2.17 + idepatches, hde (i.e., on the HPT366) at UDMA(66):
I was unable to cause any corruption despite my best efforts

kernel 2.4.0-test11-ac4, hde at UDMA(66):
Corrupted first test.

kernel 2.4.0-test11-ac4, hda at UDMA(33):
I was unable to cause any corruption despite my best efforts

kernel 2.4.0-test11-ac4, hde at UDMA(33) [i.e., using a 40 way cable]:
I was unable to cause any corruption despite my best efforts

Or, in table form:
Kernel  Controller  Mode    Status:
2.2.17	HPT366      UDMA66  WorksForMe<tm>
2.4.0   PIIX4       UDMA33  WorksForMe<tm>
2.4.0   HPT366      UDMA33  WorksForMe<tm>
2.4.0   HPT366      UDMA66  Corruption


Further details:
The drive in question is a Seagate Barracuda 7200 rpm "ata66" 13.6gig
drive
hdparm v3.6 identifies it as

/dev/hde

 Model=ST313620A, FwRev=3.07, SerialNo=7BW0QXYA
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=0(?), BuffSize=512kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
 CurCHS=65535/1/63, CurSects=-4128706, LBA=yes, LBAsects=26692776
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2 
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 *mode2 mode3 mode4 

The system is the infamous BP6, with the latest bios and two celeron 466
cpu's, clocked at 7 * 66 MHz (=466).

The "tests" I used were crude but effective;
cp -aR /usr/src/linux /usr/src/testing/one
diff -dur /usr/src/linux /usr/src/testing/one
looking for any differences (of which there should be zero)

This was repeated for a system which was very unloaded (i.e., just
booted);
then with various other tasks running - X, Netscape, a simple program
that mallocs 100 Mb. Since the machine has 128 Mb, this program should
force the computer to the edge of swap - which I have previously noted
to alter the rate of corruption.
Also two simultaneous cp's were run to further load the hdd system :)


As an interesting observation; Linux 2.4 is more "aggressive" about swap
than 2.2; 2.2 leaves all of the 100 Mb program resident, and uses ~18 Mb
of cache. 2.4 swaps some of it out, to offer more cache. 2.4 is also
more "usable" with the HDD thrashing than 2.2; response times are
snappier, etc. etc.
Well done.


Since there doesn't appear to be any corruption in UDMA66 mode in 2.2, I
don't feel the hardware to be totally broken; instead I feel the 2.4
driver is not-quite-right. I will remain at UDMA33 on the HPT controller
in 2.4 for the time being; although I am amiable to testing UDMA66 some
more :)


Goodnight And Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-12-09 10:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-09  9:43 Gerard Sharp [this message]
2000-12-09  9:57 ` HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11 Andre Hedrick
2000-12-10  3:26   ` Gerard Sharp
2000-12-10 12:15     ` Hakan Lennestal
2000-12-10 16:25       ` David Woodhouse
2000-12-10 17:17       ` Andre Hedrick
2000-12-10 19:01         ` Hakan Lennestal
2000-12-10 21:07           ` Gerard Sharp
2000-12-11  8:03           ` Andre Hedrick
2000-12-10  3:30   ` Gerard Sharp
  -- strict thread matches above, loose matches on Subject: below --
2000-12-05 20:34 Winfried Truemper
2000-12-04 16:39 Gerard Sharp
2000-12-01 11:04 Gerard Sharp
2000-12-02 16:25 ` Gnea
2000-12-04 16:10   ` Gerard Sharp
2000-12-04 20:49     ` Dan Hollis
2000-12-04 21:27       ` Richard Torkar
2000-12-04 21:41         ` Dan Hollis
2000-12-04 21:51           ` Mike Dresser
2000-12-06 10:33       ` Gerard Sharp
2000-12-06 11:23         ` kernel
2000-12-07  9:23           ` Gerard Sharp

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=3A31FEC9.B824E695@ihug.co.nz \
    --to=gsharp@ihug.co.nz \
    --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