Re: NForce2 pseudoscience stability testing (2.6.0-test11)

[Craig Bradney]

The biggest problem is we are getting very different results here
(understatement!).

I'm running UDMA 133 on round 80w cables.

I can do a grep on kernel source, eg from /usr/src/linux
grep -R linus *
grep -R kernel *
and it happily returns all information I asked for.

Right now, I am also running grep over a 4gb dvd I recently wrote from
within 2.6. No crash.. in fact.. its still going as I type this. I can
run hdparm -I while its grepping and see its on udma2.


The one thing I DID notice when I was testing with preempt on was the
something similar to the following from the dmesg that Ross Alexander
sent (dont have the dmesg output anymore :( ):

hda: IRQ probe failed (0xfffffffa)
hdb: IRQ probe failed (0xfffffffa)
hdb: IRQ probe failed (0xfffffffa)


Now it all runs through ok as shown below.

NFORCE2: IDE controller at PCI slot 0000:00:09.0
NFORCE2: chipset revision 162
NFORCE2: not 100% native mode: will probe irqs later
NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround.
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 6Y080P0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: SONY DVD RW DRU-510A, ATAPI CD/DVD-ROM drive
hdd: SAMSUNG CD-ROM SC-152C, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63,
UDMA(133)
 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 >
hdc: ATAPI 32X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 52X CD-ROM drive, 128kB Cache, DMA

In answer to Bob's email that has just come in.. I see no IRQ7 disabled
messages.. just IRQ7 -> 0:7

Uptime is now over 5 hours with a decent amount of time idling and being
busy. 

Craig

PS.
cat /proc/interrupts
           CPU0
  0:   20104881          XT-PIC  timer
  1:      21139    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  8:          2    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:     192779    IO-APIC-edge  i8042
 14:     171638    IO-APIC-edge  ide0
 15:     101036    IO-APIC-edge  ide1
 19:    1507163   IO-APIC-level  radeon@PCI:3:0:0
 21:     276278   IO-APIC-level  ehci_hcd, NVidia nForce2, eth0
 22:          3   IO-APIC-level  ohci1394
NMI:          0
LOC:   20104718
ERR:          0
MIS:          0


On Thu, 2003-12-04 at 21:04, Jesse Allen wrote:
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/