Re: NForce2 pseudoscience stability testing (2.6.0-test11)

[Craig Bradney <cbradney@zip.com.au>]

Then again.. returned to konsole to run dmesg.. bang.. dead.

This is ALL over the place

Craig

On Thu, 2003-12-04 at 21:41, Craig Bradney wrote:
> 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/
> > 
> 
> -
> 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/
>