linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesse Allen <the3dfxdude@hotmail.com>
To: Allen Martin <AMartin@nvidia.com>, b@netzentry.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)
Date: Thu, 4 Dec 2003 13:04:15 -0700	[thread overview]
Message-ID: <20031204200415.GA183@tesore.local> (raw)
In-Reply-To: <DCB9B7AA2CAB7F418919D7B59EE45BAF49F874@mail-sc-6.nvidia.com>

On Wed, Dec 03, 2003 at 09:11:37PM -0800, Allen Martin wrote:
> I don't think there's any faulty nForce IDE hardware or we would have heard
> about it from windows users (and we haven't).  

Ok.  I have never tested a motherboard driver for a problem like this.  But I'm starting to understand more.

I went ahead and tried more configurations.  I wish I had a pci ide card with 
udma 100, but the one I have is being used =(.  So I just had to make do with 
what I have.  The test is very simple, because it is very simple to trigger it. 
I just grep something very large.  It locks up almost immediately with 2.6 + 
apic + nvidia ide with dma enabled.

I ran grep on these devices:
IDE hard disk at UDMA 100, 100 MB/s, flat cable, 80w.  grep on kernel source.
same IDE hard disk with DMA disabled, 16 MB/s. grep on kernel source.
SCSI hard disk at 20 MB/s. grep on kernel source.
IDE 24x cdrom, 11 MB/s.  grepped whole cd-rom fs, about 300 MB.

During the test runs, I tried:
bios update -- no difference (same results no matter what)
preempt on/off -- no difference (same results)

The results (uniprocessor system):
1. under 2.6.0-test11 with nvidia ide, dma enabled, apic
grep on IDE hard disk at UDMA 100 -- locks nearly immediately
and later attempt, grep on cdrom -- doesn't lock up (still will lock up with 
hard disk though)

2. under 2.6.0-test11 with nvidia ide, dma, pic
grep on IDE hard disk at UDMA 100 -- doesn't lock up

3. under 2.4.23, with nvidia ide, dma enabled, apic
grep on IDE hard disk at UDMA 100 -- doesn't lock up

4. under 2.6.0-test11 with aic7xxx, ide completely disabled, apic
grep on SCSI disk -- doesn't lock up

5. under 2.6.0-test11 with nvidia ide, dma disabled, apic
grep on IDE hard disk at 16 MB/s -- doesn't lock up


So basically, I conclude that UDMA 100 will cause a lockup nearly immediately. 
The slower interfaces speeds don't cause a lockup during the test, but that 
doesn't mean the kernel will never lock up.  So DMA does produce a lockup 
faster.  Either longer stresses are required (which means spending more time =( 
I've only had the board for two days - heh heh), or more preferably, I need to
test with another pci ide controller.  Whatever it is, it seems to be the high
speeds like UDMA 100 or perhaps similarly stressing pci devices that will do it.


> 
> The problem with comparing the nForce IDE driver against the generic IDE
> driver is that the generic IDE driver won't enable DMA, so the interrupt
> rate will be much different.  If there's some interrupt race condition in
> APIC mode, disabling DMA may mask it.
> 

Yep, you're right.


Jesse

  reply	other threads:[~2003-12-04 19:54 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-04  5:11 NForce2 pseudoscience stability testing (2.6.0-test11) Allen Martin
2003-12-04 20:04 ` Jesse Allen [this message]
2003-12-04 20:41   ` Craig Bradney
2003-12-04 20:55     ` Craig Bradney
2003-12-04 22:03       ` Bob
2003-12-05  0:07   ` OOps? was: " Mike Fedyk
  -- strict thread matches above, loose matches on Subject: below --
2003-12-04 13:07 Dan Creswell
2003-12-04 12:17 b
2003-12-04 15:19 ` Craig Bradney
2003-12-04 16:32   ` Josh McKinney
2003-12-04 17:08     ` Julien Oster
2003-12-04 17:55       ` Josh McKinney
2003-12-05 13:28 ` Pat Erley
2003-12-04  9:09 b
2003-12-04  8:59 b
2003-12-04  5:37 b
2003-12-04  7:00 ` Craig Bradney
2003-12-04  2:57 b
2003-12-04  1:41 b
2003-12-04  2:45 ` Jesse Allen
2003-12-04  7:42   ` Prakash K. Cheemplavam
2003-12-04  4:45 ` Josh McKinney
2003-12-04 11:47 ` ross.alexander
     [not found] <fa.nmlihqm.16j6n38@ifi.uio.no>
     [not found] ` <fa.f27m7i8.1vk0j84@ifi.uio.no>
2003-12-04  1:08   ` walt
2003-12-03  1:32 Allen Martin
2003-12-03  1:23 b
2003-12-03  1:30 ` Ian Kumlien
2003-12-03  0:58 Allen Martin
2003-12-03  1:09 ` Ian Kumlien
     [not found] <3FCD21E1.5080300@netzentry.com>
2003-12-03  0:28 ` Craig Bradney
2003-12-03  0:48   ` Prakash K. Cheemplavam
2003-12-03  8:15     ` Craig Bradney
2003-12-03 17:09     ` bill davidsen
     [not found]     ` <200312031709.MAA18860@gatekeeper.tmr.com>
2003-12-03 17:37       ` Prakash K. Cheemplavam
2003-12-03  0:47 ` Ian Kumlien
     [not found] <WSA7.6D.39@gated-at.bofh.it>
     [not found] ` <WTYM.3ua.7@gated-at.bofh.it>
     [not found]   ` <WVoa.73O.17@gated-at.bofh.it>
2003-11-30 13:06     ` Lenar Lõhmus
2003-11-29 10:25 bug in -test11 make xconfig Christopher Sawtell
2003-11-29 11:18 ` NForce2 pseudoscience stability testing (2.6.0-test11) Craig Bradney
2003-11-29 16:34   ` Julien Oster
2003-11-29 16:47     ` Craig Bradney
2003-11-29 16:54       ` Craig Bradney
2003-12-07 11:32     ` Jussi Laako
2003-12-07 15:49       ` Prakash K. Cheemplavam
2003-12-01 18:30   ` Pavel Machek
2003-12-01 20:20     ` Craig Bradney
     [not found] <001a01c3b515$b6030de0$0f00a8c0@client.attbi.com>
2003-11-28 15:13 ` ross.alexander
2003-11-28 16:46   ` Alistair John Strachan
2003-11-28 18:13     ` Julien Oster
2003-11-28 18:24       ` Prakash K. Cheemplavam
2003-11-29  2:55       ` Josh McKinney
2003-11-29 16:33         ` Julien Oster
2003-11-29 17:15           ` Josh McKinney
2003-12-02 10:13     ` ross.alexander
2003-12-02 21:12       ` Josh McKinney
2003-12-03 16:23       ` Julien Oster
2003-11-28 18:00   ` Julien Oster
2003-11-28 18:18     ` Prakash K. Cheemplavam

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=20031204200415.GA183@tesore.local \
    --to=the3dfxdude@hotmail.com \
    --cc=AMartin@nvidia.com \
    --cc=b@netzentry.com \
    --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;
as well as URLs for NNTP newsgroup(s).