Re: NForce2 pseudoscience stability testing (2.6.0-test11)

Craig Bradney
2003-12-04T20:41:56Z

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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>