Why does my 40 Megabyte per second IDE drive, transfer files at best at 1-2
Megabytes per second? Can anyone prove that this must be the case? What is
the most efficient way to convince anyone who reads this that it can't be
proven because a counter example exists?
I wish to be personally CC'ed the answers/comments posted to the list in
response to this posting.
This is my first attempt at being part of the process. Please give me some
time to adjust.
On Fri, 9 Nov 2001, Ben Israel wrote:
> Why does my 40 Megabyte per second IDE drive, transfer files at best
> at 1-2 Megabytes per second?
Sounds like you're not using IDE DMA:
# hdparm -d1 /dev/hda
(not enabled by default because it corrupts data with some
old chipsets and/or disks)
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
"Ben Israel" <[email protected]> writes:
> Why does my 40 Megabyte per second IDE drive, transfer files at best at 1-2
> Megabytes per second? Can anyone prove that this must be the case? What is
> the most efficient way to convince anyone who reads this that it can't be
> proven because a counter example exists?
I had a drive that did something this (it was really slow on reads and
normal speed on writes, funnily enough). I finally compared it to
another drive in the same machine which worked normally and decided
that it was a failing drive (after trying many different kernels).
The replacement works fine.
So don't rule out hardware, either a bad drive or an incompatibility
between your drive and your IDE controller.
> I wish to be personally CC'ed the answers/comments posted to the list in
> response to this posting.
Say "please" next time.
> This is my first attempt at being part of the process. Please give me some
> time to adjust.
A less arrogant tone would be a good start.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
On Fri Nov 09, 2001 at 08:31:32PM -0200, Rik van Riel wrote:
> On Fri, 9 Nov 2001, Ben Israel wrote:
>
> > Why does my 40 Megabyte per second IDE drive, transfer files at best
> > at 1-2 Megabytes per second?
>
> Sounds like you're not using IDE DMA:
>
> # hdparm -d1 /dev/hda
>
> (not enabled by default because it corrupts data with some
> old chipsets and/or disks)
But wouldn't it make more sense to enable DMA by default, except
for a set of blacklisted chipsets, rather then disabling it for
everybody just because some older chipsets are crap?
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Fri, 9 Nov 2001, Erik Andersen wrote:
> On Fri Nov 09, 2001 at 08:31:32PM -0200, Rik van Riel wrote:
> > On Fri, 9 Nov 2001, Ben Israel wrote:
> >
> > > Why does my 40 Megabyte per second IDE drive, transfer files at best
> > > at 1-2 Megabytes per second?
> > # hdparm -d1 /dev/hda
> >
> > (not enabled by default because it corrupts data with some
> > old chipsets and/or disks)
>
> But wouldn't it make more sense to enable DMA by default, except
> for a set of blacklisted chipsets, rather then disabling it for
> everybody just because some older chipsets are crap?
The kernel does this, but only if CONFIG_IDEDMA_AUTO
is enabled ...
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
> > # hdparm -d1 /dev/hda
> >
> > (not enabled by default because it corrupts data with some
> > old chipsets and/or disks)
>
> But wouldn't it make more sense to enable DMA by default, except
> for a set of blacklisted chipsets, rather then disabling it for
> everybody just because some older chipsets are crap?
Its a configuration option. Most vendors I know set it to enable DMA except
on blacklisted or non PCI devices
On Fri Nov 09, 2001 at 08:57:07PM -0200, Rik van Riel wrote:
> >
> > But wouldn't it make more sense to enable DMA by default, except
> > for a set of blacklisted chipsets, rather then disabling it for
> > everybody just because some older chipsets are crap?
>
> The kernel does this, but only if CONFIG_IDEDMA_AUTO
> is enabled ...
That seems to be the theory. In practice every system in my house has
that option enabled and yet only some controllers boot up with DMA enabled...
For example lets look at the following case. This system has
an intel chipset builtin and a Promise PCI card.
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
PDC20267: IDE controller on PCI bus 00 dev 68
PCI: Found IRQ 5 for device 00:0d.0
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdg:pio, hdh:DMA
hda: IBM-DPTA-373420, ATA DISK drive
hdd: PCRW804, ATAPI CD/DVD-ROM drive
hde: IBM-DTLA-307045, ATA DISK drive
hdg: IBM-DTLA-307045, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xac00-0xac07,0xb002 on irq 5
ide3 at 0xb400-0xb407,0xb802 on irq 5
hda: 66055248 sectors (33820 MB) w/1961KiB Cache, CHS=4111/255/63, UDMA(33)
hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
Partition check:
hda: hda1 hda2
hde: hde1
hdg: hdg1
So the Intel one came up with DMA enabled, No problem there.
The Promise controller has two identical 46.1GB IBM-DTLA-307045 7200
rpm hard drives on it. The controller is capable of ATA100. The hard
drives are capable of ATA100. And yet even with CONFIG_IDEDMA_AUTO
set, these drives both come up running 3.39 MB/s.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Hi.
> Why does my 40 Megabyte per second IDE drive, transfer files at best at 1-2
> Megabytes per second? Can anyone prove that this must be the case? What is
> the most efficient way to convince anyone who reads this that it can't be
> proven because a counter example exists?
>
> I wish to be personally CC'ed the answers/comments posted to the list in
> response to this posting.
>
> This is my first attempt at being part of the process. Please give me some
> time to adjust.
40Megabyte per second you say. Well, if it benchmarks at 1-2 Megabytes
per second it sounds like a 2 Megabytes per second drive to me, not a 40
Megabytes per second drive.
But, to try to speed it up, make sure you're running with DMA mode enabled.
hdparm -d1 /dev/hdx where x = number of drive (a=primary master,
b=primary slave, c=secondary master, etc).
But, apart from that, if it indeed is a real problem, what's the name of
the motherboard, chipset, hard drive, what linux kernel revision are you
running and do you use any special patches or tricks with it?
// Stefan
On Fri, Nov 09, 2001 at 04:20:28PM -0700, Erik Andersen wrote:
> On Fri Nov 09, 2001 at 08:57:07PM -0200, Rik van Riel wrote:
> > >
> > > But wouldn't it make more sense to enable DMA by default, except
> > > for a set of blacklisted chipsets, rather then disabling it for
> > > everybody just because some older chipsets are crap?
> >
> > The kernel does this, but only if CONFIG_IDEDMA_AUTO
> > is enabled ...
>
> That seems to be the theory. In practice every system in my house has
> that option enabled and yet only some controllers boot up with DMA enabled...
>
> For example lets look at the following case. This system has
> an intel chipset builtin and a Promise PCI card.
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev 39
> PIIX4: chipset revision 1
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> PDC20267: IDE controller on PCI bus 00 dev 68
> PCI: Found IRQ 5 for device 00:0d.0
> PDC20267: chipset revision 2
> PDC20267: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:DMA, hdf:DMA
> ide3: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdg:pio, hdh:DMA
> hda: IBM-DPTA-373420, ATA DISK drive
> hdd: PCRW804, ATAPI CD/DVD-ROM drive
> hde: IBM-DTLA-307045, ATA DISK drive
> hdg: IBM-DTLA-307045, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0xac00-0xac07,0xb002 on irq 5
> ide3 at 0xb400-0xb407,0xb802 on irq 5
> hda: 66055248 sectors (33820 MB) w/1961KiB Cache, CHS=4111/255/63, UDMA(33)
> hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
> hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
> Partition check:
> hda: hda1 hda2
> hde: hde1
> hdg: hdg1
>
> So the Intel one came up with DMA enabled, No problem there.
>
> The Promise controller has two identical 46.1GB IBM-DTLA-307045 7200
> rpm hard drives on it. The controller is capable of ATA100. The hard
> drives are capable of ATA100. And yet even with CONFIG_IDEDMA_AUTO
> set, these drives both come up running 3.39 MB/s.
Here all drives "default" to UDMA:
(Kernel is 2.4.9 vanilla)
Second Controller is an Promise Ultra 100 TX2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ServerWorks OSB4: IDE controller on PCI bus 00 dev 79
ServerWorks OSB4: chipset revision 0
ServerWorks OSB4: not 100%% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
PDC20268: IDE controller on PCI bus 02 dev 08
PDC20268: chipset revision 1
PDC20268: not 100%% native mode: will probe irqs later
PDC20268: ROM enabled at 0xfebf8000
PDC20268: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary MASTER Mode.
ide2: BM-DMA at 0xef90-0xef97, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xef98-0xef9f, BIOS settings: hdg:pio, hdh:pio
hda: IBM-DTTA-351010, ATA DISK drive
hde: IBM-DTLA-307045, ATA DISK drive
hdf: IBM-DTLA-307045, ATA DISK drive
hdg: WDC WD1000BB-32CCB0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0xefe0-0xefe7,0xefae on irq 24
ide3 at 0xefa0-0xefa7,0xefaa on irq 24
hda: 19807200 sectors (10141 MB) w/466KiB Cache, CHS=1232/255/63, UDMA(33)
hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100)
hdf: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100)
hdg: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(100)
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Stefan Smietanowski wrote:
> Hi.
>
>> Why does my 40 Megabyte per second IDE drive, transfer files at best
>> at 1-2
>> Megabytes per second? Can anyone prove that this must be the case?
>> What is
>> the most efficient way to convince anyone who reads this that it can't be
>> proven because a counter example exists?
>>
>> I wish to be personally CC'ed the answers/comments posted to the list in
>> response to this posting.
>>
>> This is my first attempt at being part of the process. Please give me
>> some
>> time to adjust.
>
>
> 40Megabyte per second you say. Well, if it benchmarks at 1-2 Megabytes
> per second it sounds like a 2 Megabytes per second drive to me, not a 40
> Megabytes per second drive.
>
> But, to try to speed it up, make sure you're running with DMA mode enabled.
>
> hdparm -d1 /dev/hdx where x = number of drive (a=primary master,
> b=primary slave, c=secondary master, etc).
>
> But, apart from that, if it indeed is a real problem, what's the name of
> the motherboard, chipset, hard drive, what linux kernel revision are you
> running and do you use any special patches or tricks with it?
>
I once had a problem where the cable was attached in the middle, and the end was
not attached to anything (the cable supported two drives). After changing to
the end connector, it went from 2MB to 30+MB....
Ben
> // Stefan
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
Erik Andersen wrote:
>The Promise controller has two identical 46.1GB IBM-DTLA-307045 7200
>rpm hard drives on it. The controller is capable of ATA100. The hard
>drives are capable of ATA100. And yet even with CONFIG_IDEDMA_AUTO
>set, these drives both come up running 3.39 MB/s.
Interesting...
You've got the PDC20267 chipset, I have two cards with the PDC20268
chipset (Ultra TX2/100) and they both work fine - although the BIOS
setting shows as PIO, the kernel correctly enables UDMA-100 for the
Maxtor drives attached to them for me (CONFIG_IDEDMA_AUTO is on.)
And, I have an identical IBM drive on my motherboard (VIA) controller
and it comes up fine too, so it isn't the hard drive....
Linux rivendell.arnor.net 2.4.14-pre6 #2 SMP Wed Oct 31 21:29:03 PST 2001
i686 unknown
...
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:DMA
PDC20268: IDE controller on PCI bus 00 dev 90
PDC20268: chipset revision 2
PDC20268: not 100% native mode: will probe irqs later
PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER
Mode.
ide2: BM-DMA at 0xac00-0xac07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xac08-0xac0f, BIOS settings: hdg:pio, hdh:pio
PDC20268: IDE controller on PCI bus 00 dev 98
PDC20268: chipset revision 1
PDC20268: not 100% native mode: will probe irqs later
PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER
Mode.
ide4: BM-DMA at 0xc000-0xc007, BIOS settings: hdi:pio, hdj:pio
ide5: BM-DMA at 0xc008-0xc00f, BIOS settings: hdk:pio, hdl:pio
hda: IBM-DTLA-307045, ATA DISK drive
hdc: PLEXTOR CD-R PX-W1210A, ATAPI CD/DVD-ROM drive
hdd: TOSHIBA DVD-ROM SD-M1402, ATAPI CD/DVD-ROM drive
hde: Maxtor 4W060H4, ATA DISK drive
hdg: Maxtor 4W060H4, ATA DISK drive
hdi: Maxtor 4W060H4, ATA DISK drive
hdk: Maxtor 4W060H4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0x9c00-0x9c07,0xa002 on irq 18
ide3 at 0xa400-0xa407,0xa802 on irq 18
ide4 at 0xb000-0xb007,0xb402 on irq 19
ide5 at 0xb800-0xb807,0xbc02 on irq 19
hda: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(66)
hde: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
UDMA(100)
hdg: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
UDMA(100)
hdi: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
UDMA(100)
hdk: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
UDMA(100)
...
Torrey Hoffman
> Why does my 40 Megabyte per second IDE drive, transfer
> files at best at 1-2 Megabytes per second?
Keep in mind that some disk benchmarks just read/write long contiguous
regions of the disk, whereas the files you are copying may be fragmented.
So, while your drive may be able to sustain 40 MB/sec on a contiguous
region, it might slow down a lot if it has to seek to different parts of a
fragmented file, or between many files.
Actually while I'm on this subject - does anyone have experience with
"preallocating" files for low-latency transfers? e.g. if I know I'm going to
capture several GB of video to disk, will it reduce I/O latency if I
truncate the destination file to the proper size and fill it with zeros
beforehand? (I assume it helps for the fs to be as empty as possible) Are
any filesystems particularly good/bad for cases like this?
Regards,
Dan
try
hdparm -d1 /dev/hda
hdparm -d1 /dev/hdb
and test them now
On Fri, 9 Nov 2001, Torrey Hoffman wrote:
> Erik Andersen wrote:
>
> >The Promise controller has two identical 46.1GB IBM-DTLA-307045 7200
> >rpm hard drives on it. The controller is capable of ATA100. The hard
> >drives are capable of ATA100. And yet even with CONFIG_IDEDMA_AUTO
> >set, these drives both come up running 3.39 MB/s.
>
> Interesting...
>
> You've got the PDC20267 chipset, I have two cards with the PDC20268
> chipset (Ultra TX2/100) and they both work fine - although the BIOS
> setting shows as PIO, the kernel correctly enables UDMA-100 for the
> Maxtor drives attached to them for me (CONFIG_IDEDMA_AUTO is on.)
>
> And, I have an identical IBM drive on my motherboard (VIA) controller
> and it comes up fine too, so it isn't the hard drive....
>
>
> Linux rivendell.arnor.net 2.4.14-pre6 #2 SMP Wed Oct 31 21:29:03 PST 2001
> i686 unknown
> ...
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 16
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1
> ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:DMA
> PDC20268: IDE controller on PCI bus 00 dev 90
> PDC20268: chipset revision 2
> PDC20268: not 100% native mode: will probe irqs later
> PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER
> Mode.
> ide2: BM-DMA at 0xac00-0xac07, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0xac08-0xac0f, BIOS settings: hdg:pio, hdh:pio
> PDC20268: IDE controller on PCI bus 00 dev 98
> PDC20268: chipset revision 1
> PDC20268: not 100% native mode: will probe irqs later
> PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER
> Mode.
> ide4: BM-DMA at 0xc000-0xc007, BIOS settings: hdi:pio, hdj:pio
> ide5: BM-DMA at 0xc008-0xc00f, BIOS settings: hdk:pio, hdl:pio
> hda: IBM-DTLA-307045, ATA DISK drive
> hdc: PLEXTOR CD-R PX-W1210A, ATAPI CD/DVD-ROM drive
> hdd: TOSHIBA DVD-ROM SD-M1402, ATAPI CD/DVD-ROM drive
> hde: Maxtor 4W060H4, ATA DISK drive
> hdg: Maxtor 4W060H4, ATA DISK drive
> hdi: Maxtor 4W060H4, ATA DISK drive
> hdk: Maxtor 4W060H4, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0x9c00-0x9c07,0xa002 on irq 18
> ide3 at 0xa400-0xa407,0xa802 on irq 18
> ide4 at 0xb000-0xb007,0xb402 on irq 19
> ide5 at 0xb800-0xb807,0xbc02 on irq 19
> hda: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(66)
> hde: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
> UDMA(100)
> hdg: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
> UDMA(100)
> hdi: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
> UDMA(100)
> hdk: 117347328 sectors (60082 MB) w/2048KiB Cache, CHS=116416/16/63,
> UDMA(100)
> ...
>
> Torrey Hoffman
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat Nov 10, 2001 at 05:47:15PM +0100, Davidovac Zoran wrote:
> try
> hdparm -d1 /dev/hda
> hdparm -d1 /dev/hdb
> and test them now
Sure. But that isn't the point. The point is that even if the
drive is capable and the chipset is capable, there still seem to
be corner cases where DMA is not enabled.
In my case, the chipset and drives in my box are both known to
work with DMA enabled and the ide chipset is even in the IDEDMA
white list. But DMA is still not being enabled by default, so
there is a bug somewhere,
So why don't I want to hard code hdparm in an init script? Lets
suppose for a moment there are programs that need to run on all
sorts of strange hardware and which depend on trying to run the
hard drives as fast as possible. For example, think of the
installer for your favorite distro. Redhat or Debian or whatever
couldn't very well put 'hdparm -d1 /dev/hda' in the init scipts
since for all they know there might be a cmd640 under the hood...
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Fri, 9 Nov 2001, Erik Andersen wrote:
> On Fri Nov 09, 2001 at 08:57:07PM -0200, Rik van Riel wrote:
> > >
> > > But wouldn't it make more sense to enable DMA by default, except
> > > for a set of blacklisted chipsets, rather then disabling it for
> > > everybody just because some older chipsets are crap?
> >
> > The kernel does this, but only if CONFIG_IDEDMA_AUTO
> > is enabled ...
>
> That seems to be the theory. In practice every system in my house has
> that option enabled and yet only some controllers boot up with DMA enabled...
>
> For example lets look at the following case. This system has
> an intel chipset builtin and a Promise PCI card.
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev 39
> PIIX4: chipset revision 1
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> PDC20267: IDE controller on PCI bus 00 dev 68
> PCI: Found IRQ 5 for device 00:0d.0
> PDC20267: chipset revision 2
> PDC20267: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:DMA, hdf:DMA
> ide3: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdg:pio, hdh:DMA
> hda: IBM-DPTA-373420, ATA DISK drive
> hdd: PCRW804, ATAPI CD/DVD-ROM drive
> hde: IBM-DTLA-307045, ATA DISK drive
> hdg: IBM-DTLA-307045, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0xac00-0xac07,0xb002 on irq 5
> ide3 at 0xb400-0xb407,0xb802 on irq 5
> hda: 66055248 sectors (33820 MB) w/1961KiB Cache, CHS=4111/255/63, UDMA(33)
> hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
> hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
> Partition check:
> hda: hda1 hda2
> hde: hde1
> hdg: hdg1
>
> So the Intel one came up with DMA enabled, No problem there.
>
> The Promise controller has two identical 46.1GB IBM-DTLA-307045 7200
> rpm hard drives on it. The controller is capable of ATA100. The hard
> drives are capable of ATA100. And yet even with CONFIG_IDEDMA_AUTO
> set, these drives both come up running 3.39 MB/s.
I've got the same setup and things work fine. Do you have the "Special UDMA
feature" enabled in the Promise driver configuration portion of the kernel
config? Perhaps it specifically needs that while any other EIDE driver (like
the embedded PIIX4) would already use DMA..
Perhaps Andre can give us a final answer :)
-------------------------------------------------------------------------------
Maxwell Spangler
Program Writer
Greenbelt, Maryland, U.S.A.
Washington D.C. Metropolitan Area
On Sun, 11 Nov 2001, Maxwell Spangler wrote:
> On Fri, 9 Nov 2001, Erik Andersen wrote:
>
> > On Fri Nov 09, 2001 at 08:57:07PM -0200, Rik van Riel wrote:
> > > >
> > > > But wouldn't it make more sense to enable DMA by default, except
> > > > for a set of blacklisted chipsets, rather then disabling it for
> > > > everybody just because some older chipsets are crap?
> > >
> > > The kernel does this, but only if CONFIG_IDEDMA_AUTO
> > > is enabled ...
> >
> > That seems to be the theory. In practice every system in my house has
> > that option enabled and yet only some controllers boot up with DMA enabled...
> >
> > For example lets look at the following case. This system has
> > an intel chipset builtin and a Promise PCI card.
> >
> > Uniform Multi-Platform E-IDE driver Revision: 6.31
> > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > PIIX4: IDE controller on PCI bus 00 dev 39
> > PIIX4: chipset revision 1
> > PIIX4: not 100% native mode: will probe irqs later
> > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> > PDC20267: IDE controller on PCI bus 00 dev 68
> > PCI: Found IRQ 5 for device 00:0d.0
> > PDC20267: chipset revision 2
> > PDC20267: not 100% native mode: will probe irqs later
> > ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:DMA, hdf:DMA
> > ide3: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdg:pio, hdh:DMA
> > hda: IBM-DPTA-373420, ATA DISK drive
> > hdd: PCRW804, ATAPI CD/DVD-ROM drive
> > hde: IBM-DTLA-307045, ATA DISK drive
> > hdg: IBM-DTLA-307045, ATA DISK drive
> > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > ide1 at 0x170-0x177,0x376 on irq 15
> > ide2 at 0xac00-0xac07,0xb002 on irq 5
> > ide3 at 0xb400-0xb407,0xb802 on irq 5
> > hda: 66055248 sectors (33820 MB) w/1961KiB Cache, CHS=4111/255/63, UDMA(33)
> > hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
> > hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63
> > Partition check:
> > hda: hda1 hda2
> > hde: hde1
> > hdg: hdg1
> >
> > So the Intel one came up with DMA enabled, No problem there.
> >
> > The Promise controller has two identical 46.1GB IBM-DTLA-307045 7200
> > rpm hard drives on it. The controller is capable of ATA100. The hard
> > drives are capable of ATA100. And yet even with CONFIG_IDEDMA_AUTO
> > set, these drives both come up running 3.39 MB/s.
>
> I've got the same setup and things work fine. Do you have the "Special UDMA
> feature" enabled in the Promise driver configuration portion of the kernel
> config? Perhaps it specifically needs that while any other EIDE driver (like
> the embedded PIIX4) would already use DMA..
>
> Perhaps Andre can give us a final answer :)
> -------------------------------------------------------------------------------
> Maxwell Spangler
> Program Writer
> Greenbelt, Maryland, U.S.A.
> Washington D.C. Metropolitan Area
>
One needs to set the chipsets and not allow it to be in the default setup.
> > PDC20267: IDE controller on PCI bus 00 dev 68
> > PCI: Found IRQ 5 for device 00:0d.0
> > PDC20267: chipset revision 2
> > PDC20267: not 100% native mode: will probe irqs later
> > ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:DMA, hdf:DMA
> > ide3: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdg:pio, hdh:DMA
These lines tell me that you do not have the pdc202xx compiled into the
kernel. Therefore you have not way to setup the host device pair.
If the chipset code was compiled into the kernel, there would have been a
line reporting about the ultra_bits and master/pci modes of each channel.
The significance of the tuning code is not just for init events.
Linux is the first and only OS to have the autodma down grade feature
(Intel borrowed my model, approved by me). This allows for kernel to auto
reconfigure the drive to stablize the transfer rates to protect the data.
Of course the ATA hardware has iCRC's un Ultra modes, but excessive
retries which are/will be successfully defeat the power of Ultra
transfers. Therefore the tuning code in conjunction the the
auto-down-grade functions will reduce the transfer rates until the iCRC's
go away. This is the 0x84/0x51 error pairs. There are various reasons
that can cause this error to occur; however, the first stage is to
stablize the transport data path and then allow the SA or EU to examine
the problems.
My current folly in the code base is chipsets are not modular, but then
one has the problem to only allow booting of legacy hardware during
install. This is another story to be addressed, whenever 2.5 begins.
As for the PIIX4 AB/EB that is a total mess at the hardware layer.
I have an ugly fix for linux but it is violent in the noise maker and is
not acceptable as standard use.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
On Sun, 11 Nov 2001, Andre Hedrick wrote:
> The significance of the tuning code is not just for init events.
> Linux is the first and only OS to have the autodma down grade feature
> (Intel borrowed my model, approved by me). This allows for kernel to auto
> reconfigure the drive to stablize the transfer rates to protect the data.
> Of course the ATA hardware has iCRC's un Ultra modes, but excessive
> retries which are/will be successfully defeat the power of Ultra
> transfers. Therefore the tuning code in conjunction the the
> auto-down-grade functions will reduce the transfer rates until the iCRC's
> go away. This is the 0x84/0x51 error pairs. There are various reasons
> that can cause this error to occur; however, the first stage is to
> stablize the transport data path and then allow the SA or EU to examine
> the problems.
So the system will boot at ATA100, for example, and if errors are seen,
downgrade step by step until a satisfactory level is reached. Perhaps, ATA66
or ATA33 and the system would continue proper operation still at a "somewhat
fast" (as compared to PIO) speed level AND in DMA mode, not PIO. My situation
with the 6.31 driver has DMA being disabled by the driver when errors are
seen, as I think you have clearly stated.
?? I'm assuming no to this, but I'm curious: Is there any chance the driver
would "speed up" the transfers? Ie: after a period of time at ATA33, would it
try ATA66, 100 again? I suppose this makes more sense for things like
serial/modem communications where problems could come and go, but if one is
experiencing problems between the ATA circuitry, cable and drive, they'll
start good, get worse and never recover..?
-------------------------------------------------------------------------------
Maxwell Spangler
Program Writer
Greenbelt, Maryland, U.S.A.
Washington D.C. Metropolitan Area
On Sun, 11 Nov 2001, Maxwell Spangler wrote:
> On Sun, 11 Nov 2001, Andre Hedrick wrote:
>
> > The significance of the tuning code is not just for init events.
> > Linux is the first and only OS to have the autodma down grade feature
> > (Intel borrowed my model, approved by me). This allows for kernel to auto
> > reconfigure the drive to stablize the transfer rates to protect the data.
> > Of course the ATA hardware has iCRC's un Ultra modes, but excessive
> > retries which are/will be successfully defeat the power of Ultra
> > transfers. Therefore the tuning code in conjunction the the
> > auto-down-grade functions will reduce the transfer rates until the iCRC's
> > go away. This is the 0x84/0x51 error pairs. There are various reasons
> > that can cause this error to occur; however, the first stage is to
> > stablize the transport data path and then allow the SA or EU to examine
> > the problems.
>
> So the system will boot at ATA100, for example, and if errors are seen,
> downgrade step by step until a satisfactory level is reached. Perhaps, ATA66
> or ATA33 and the system would continue proper operation still at a "somewhat
> fast" (as compared to PIO) speed level AND in DMA mode, not PIO. My situation
> with the 6.31 driver has DMA being disabled by the driver when errors are
> seen, as I think you have clearly stated.
>
> ?? I'm assuming no to this, but I'm curious: Is there any chance the driver
> would "speed up" the transfers? Ie: after a period of time at ATA33, would it
> try ATA66, 100 again? I suppose this makes more sense for things like
> serial/modem communications where problems could come and go, but if one is
> experiencing problems between the ATA circuitry, cable and drive, they'll
> start good, get worse and never recover..?
>
> -------------------------------------------------------------------------------
> Maxwell Spangler
> Program Writer
> Greenbelt, Maryland, U.S.A.
> Washington D.C. Metropolitan Area
>
Hi Maxwell,
A system will launch PIO and if there is a driver it will be feature
enabled to max performance and auto scaled if there are problems
encountered.
The current code has a mistake that is not fatal, but regardless wrong.
Ultra 100|66|44|33|25|16 -- MW DMA 2|1|0 -- SW DMA 2|1|0 -- PIO4
5 4 3 2 1 0
The fault is that you lose the iCRC features in Ultra so dropping to
Multi/Single word DMAs only gain speed w/ out a safety net.
The current patch code series does a single reduction of transfer rate per
counting 10 iCRC events, and no other errors are allowed.
Ultra 133|100|66|44|33|25|16|---PIO4
6 5 4 3 2 1 0 ---
You need to enable the chipset code otherwise the driver will not allow
DMA to run in a sane mode.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
On Sun Nov 11, 2001 at 02:24:27PM -0500, Maxwell Spangler wrote:
>
> I've got the same setup and things work fine. Do you have the "Special UDMA
> feature" enabled in the Promise driver configuration portion of the kernel
> config? Perhaps it specifically needs that while any other EIDE driver (like
> the embedded PIIX4) would already use DMA..
I had PDC202XX enabed in my kernel for my target, but had stupidly
forgotten to enable it in the kernel I was running my tests on.
A voice booms: "You feel foolish. Goodbye level 3!",
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--