sc1d = IN_BYTE(high_16 + 0x001d);
if (HWIF(drive)->channel) {
if ((sc1d & 0x50) == 0x50) goto somebody_else;
else if ((sc1d & 0x40) == 0x40)
return (dma_stat & 4) == 4;
} else {
if ((sc1d & 0x05) == 0x05) goto somebody_else;
else if ((sc1d & 0x04) == 0x04)
return (dma_stat & 4) == 4;
}
somebody_else:
return (dma_stat & 4) == 4; /* return 1 if INTR asserted */
Please note the old chips have an interrupt parser and owner ship.
The new chips do not have this feature reported.
Once you hit high load/io the cards/driver get confused.
Who owns the interrupt as retruned and expect more reports dma_intr error
35 to show up.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Wed, 17 Apr 2002, Baldur Norddahl wrote:
> Hi,
>
> I have been doing some simple benchmarks on my IDE system. It got 12 disks
> and a system disk. The 12 disks are organized in two raids like this:
>
> Personalities : [raid5]
> read_ahead 1024 sectors
> md1 : active raid5 hds1[0] hdo1[1] hdk1[2] hdg1[3]
> 480238656 blocks level 5, 32k chunk, algorithm 0 [4/4] [UUUU]
>
> md0 : active raid5 hdt1[6] hdq1[1] hdp1[7] hdm1[0] hdl1[2] hdi1[4] hdh1[3] hde1[5]
> 547054144 blocks level 5, 4k chunk, algorithm 0 [8/8] [UUUUUUUU]
>
> unused devices: <none>
>
> The md0 raid is eight 80 GB Western Digital disks. The md1 raid is four 160
> GB Maxtor disks.
>
> I am using two Promise Technology ultradma133 TX2 controllers and two
> Promise Technologu ultradma100 TX2 controllers. The two ultradma133
> controllers are on a 66 MHz PCI bus, while the two ultradma100 controllers
> are on a 33 MHz PCI bus.
>
> An example of a test run is:
>
> echo Testing hdo1, hds1 and hdk1
> time dd if=/dev/hdo1 of=/dev/null bs=1M count=1k &
> time dd if=/dev/hds1 of=/dev/null bs=1M count=1k &
> time dd if=/dev/hdk1 of=/dev/null bs=1M count=1k &
> wait
>
> I am then watching the progress in another window with vmstat 1. I copied
> typical lines for each test below. What interrest me is the "bi" column for
> the transfer rate. Ad the "id" column as an indicator of how much CPU is being
> spend.
>
> This test is done on a SMP system with kernel 2.4.18 with IDE patches.
>
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
>
> hdt:
> 0 1 0 26096 6600 159888 599004 0 0 34432 0 709 1690 1 10 88
>
> hdt and hdg:
> 0 2 1 26096 6428 70736 687496 0 0 64768 0 1167 2931 1 25 74
>
> hdt, hdg and hdp:
> 0 3 0 26092 7832 42632 712712 0 0 75620 0 1383 3242 7 33 60
>
> hdt, hdg, hdp and hdm:
> 0 4 0 26092 6400 42464 713044 0 0 74376 0 1374 3289 0 30 70
>
> hdt, hdg, hdp, hdm and hdl:
> 0 5 0 26092 6196 42412 712188 0 0 107008 696 2000 4397 5 43 51
>
> hdt, hdg, hdp, hdm, hdl and hdi:
> 2 4 1 26172 5480 42184 713432 0 0 137104 0 2137 4602 5 75 20
>
> hdt, hdg, hdp, hdm, hdl, hdi and hdh:
> 5 2 1 27324 5020 35268 737336 0 108 144640 108 2177 2271 0 99 0
>
> hdt, hdg, hdp, hdm, hdl, hdi, hdh and hde:
> 4 4 1 27324 5420 35572 735752 0 0 143796 0 2102 2180 1 99 0
>
> hdo:
> 0 1 0 27324 7032 55732 666408 0 0 36352 0 710 1796 0 12 87
>
> hdo and hds:
> 0 2 1 27324 6516 40012 691588 0 0 72576 0 1264 3311 0 24 75
>
> hdo, hds and hdk:
> 0 3 0 27316 6012 40048 692088 0 0 108944 484 1970 4523 0 50 50
>
> hdo, hds, hdk and hdg:
> 4 0 1 27316 5552 40080 694124 0 0 134572 0 2252 4825 1 70 29
>
> md0:
> 1 0 0 27324 13460 38104 692140 0 0 76676 0 4639 2611 4 74 22
>
> md1:
> 0 1 0 27316 10224 40340 697780 0 0 69504 0 1893 3892 1 55 44
>
> md0 and md1:
> 2 1 1 27316 7188 40224 675200 0 0 81470 164 3935 2389 9 77 14
>
> It is clear that the 33 MHz PCI bus maxes out at 75 MB/s. Is there a reason
> it doesn't reach 132 MB/s?
>
> Second, why are the md devices so slow? I would have expected it to reach
> 130+ MB/s on both md0 and md1. It even has spare CPU time to do it with.
>
> Another issue is when the system is under heavy load this often happens:
>
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdt: dma_intr: bad DMA status (dma_stat=75)
> hdt: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: timeout waiting for DMA
> PDC202XX: Primary channel reset.
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hdq: dma_intr: bad DMA status (dma_stat=35)
> hdq: dma_intr: status=0x50 { DriveReady SeekComplete }
> hdq: timeout waiting for DMA
> PDC202XX: Primary channel reset.
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> etc.
>
> It did not happen during the test above though.
>
> Baldur
> -
> 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/