I was talking to a couple of friends who also run 2.4.x, they said they
burn CD's all the time using DMA, and not PIO.
So I looked into the matter, apparently, the kernel sets my hd{b,c}
(both Plextor 12/10/32A's) drives DMA to disabled.
[war@war war]$ dmesg | grep -i dma
Activating ISA DMA hang workarounds.
VP_IDE: VIA vt82c596b (rev 12) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63, UDMA(66)
hdb: DMA disabled
hdc: DMA disabled
[war@war war]$
[war@war war]$ lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo
PRO133x] (rev 44)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo
MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South]
(rev 12)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus
Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 08)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management
(rev 20)
00:10.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:10.1 Input device controller: Creative Labs SB Live! MIDI/Game Port
(rev 07)
00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
00:12.0 SCSI storage controller: Adaptec AHA-7850 (rev 03)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)
[war@war war]$
I even went further and tried:
append="ide-cd=ignore=hdb ide-cd=ignore=hdc"
In my lilo.conf, once again, no luck.
Can anyone offer any suggestions why others can burn CD's in DMA mode,
yet the kernel keeps disabling DMA for my burners?
Please cc me as I am not subscribed to the list, thank you.
use: hdparam -d1 /dev/<hdX>
to enable DMA, if it still says it cannot enable DMA.
try enabling the xfermode,which gives me the same
performace as DMA enabled.
hdparam -X<num> /dev/<hdX>
put num greater than 32..like 33,34 etc (for multiword DMA)
OR greater that 64....like 65 66 etc. (for UltraDMA)
-vvp
On Wed, 2003-02-26 at 05:21, jpiszcz wrote:
> Can anyone offer any suggestions why others can burn CD's in DMA mode,
> yet the kernel keeps disabling DMA for my burners?
It depends on the options your kernel was compiled with
Yes, hdparm -d1 /dev/hd{b,c} did not work on older kernels for me, but
2.4.20 appears to work successfully.
However, second question, both of my Plextors support UDMA2, and both
are on 80 PIN/IDE cables, when I enabled -d1 -X66, the kernel, it
crashed the kernel.
Feb 26 10:30:55 war kernel: hdc: drive_cmd: status=0x41 { DriveReady Error }
Feb 26 10:30:55 war kernel: hdc: drive_cmd: error=0x04
Feb 26 10:30:59 war kernel: hdc: drive_cmd: status=0x41 { DriveReady Error }
Feb 26 10:30:59 war kernel: hdc: drive_cmd: error=0x04
Feb 26 10:31:02 war kernel: hdc: drive_cmd: status=0x41 { DriveReady Error }
Feb 26 10:31:02 war kernel: hdc: drive_cmd: error=0x04
Feb 26 10:32:22 war kernel: scsi : aborting command due to timeout : pid
11206, scsi1, channel 0, id 1, lun 0 Read (10) 00 00 00 00 00 00 00 02 00
Feb 26 10:32:22 war kernel: hdc: timeout waiting for DMA
Feb 26 10:32:22 war kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 26 10:32:22 war kernel: hdc: status timeout: status=0xd8 { Busy }
Feb 26 10:32:22 war kernel: hdc: drive not ready for command
After this, X froze and the keyboard lights were blinking, I could not
change to console or anything to see the kernel messages.
1] Why does the kernel turn DMA off by default?
config: http://installkernel.tripod.com/config-2.4.20.txt
2] Why does the kernel crash when I try to enable UDMA2 on the cdrw?
[email protected] wrote:
> use: hdparam -d1 /dev/<hdX>
>
> to enable DMA, if it still says it cannot enable DMA.
> try enabling the xfermode,which gives me the same
> performace as DMA enabled.
>
> hdparam -X<num> /dev/<hdX>
> put num greater than 32..like 33,34 etc (for multiword DMA)
> OR greater that 64....like 65 66 etc. (for UltraDMA)
>
> -vvp
>
>
>
>
>
>
>
>
>
>
>
On Wed, 26 Feb 2003, jpiszcz wrote:
> Yes, hdparm -d1 /dev/hd{b,c} did not work on older kernels for me, but
> 2.4.20 appears to work successfully.
>
> However, second question, both of my Plextors support UDMA2, and both
> are on 80 PIN/IDE cables, when I enabled -d1 -X66, the kernel, it
> crashed the kernel.
>
[SNIPPED...]
This has turned out to be a FAQ. DMA is not "better"
than some other transfer mode. It's just a method.
What DMA does, is allow the CPU to do something else
while data are being transferred. With a multi-tasking
operating system, there are sometimes other things that
the CPU can be doing while a transfer is occurring.
This means that if a disk transfer is occurring using
DMA, this seems like a background operation to the user.
There are two basic kinds of DMA that occur in ix86
machines. One is called buss-mastering. This is the
kind of DMA that PCI/Bus devices that are memory-mapped
use. The other is I/O and it may use the cascaded
DMA controllers.
There is another kind of DMA in which an IDE drive tries
to perform a data transfer from I/O to memory by bypassing
the legacy DMA controllers and mucking with the I/O bits
themselves. This is variously called UDMA, "Ultra DMA",
like it's some special high-performance technique.
Using your favorite search-engine, search for UDMA
on the net sometime and see what a mess it is.
In other words, it pretends that its operations are buffered
by a PCI/Bus when, in fact, it doesn't use the PCI/Bus.
This kind of DMA sometimes works. It depends upon the cable
going to your drive being low capacity and just the right
length. The problem is that the "right" length isn't a constant.
It depends upon the speed of RAM, the CPU/cache access
pipe-line delay and numerous other things, probably even
the temperature of the room and the phase of the moon.
For DMA to work, the device performing the transfer must
do the transfer when it's the sole owner of the bus. To
do this with a PCI/Bus is easy because there is a bus
protocol that the hardware performs in a precisely-timed
manner. Once the vendors get it right, anything plugged
into that bus will work. On the other hand, IDE disk
drives, (IDE means Integrated Drive Electronics) are
connected to the motherboard with a simple transceiver.
The "smarts" necessary to acquire the bus, perform a
transfer, and release the bus, are inside the disk drive!
Some disk-drives work using DMA and some don't. So, you
try to use DMA and if your file system doesn't get corrupted,
you gain a bit of responsiveness. If your disk drive won't do
DMA, it's the disk drive, not something else! Just don't
enable DMA. It's that simple.
With IDE drives, the most reliable transfer mode is PIO. It
comes in several flavors, PIO (bytes) PIOW (words) PIOL
(longwords). With these modes, the CPU makes the transfer so
that the CPU is busy during the whole transfer time. The
transfer, using PIOL, is quite fast, a long-word every 150
nanoseconds or so. Since the CPU is never locked off the bus,
the entire transfer can complete, i.e., perhaps a whole
megabyte in one read operation. With DMA and bus-mastering,
the transfer is broken up into small groups so that the
CPU isn't locked off the bus for too long a time.
The result is that PIOL may be actually faster than DMA when
some task is I/O bound. Of course other tasks may be CPU starved
during a long transfer, but you get what you pay for.
If you want the best of all worlds, you need to get a good
SCSI Controller and some SCSI disks. Some SCSI disks have the
exact same drive components behind the SCSI interface. Don't
let this fool you. It's the buffering and isolation afforded
by the whole SCSI system that makes it perform better than
bare IDE drives. There is a CPU (or ASIC) on the SCSI board
that functions as a "secretary" or "housekeeper" to make
damn sure a transfer occurs correctly. Many retries are
transparent and it's only when there is a permanent error
that the host software even knows about it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Wed, Feb 26, 2003 at 12:02:13PM -0500, Richard B. Johnson wrote:
>
> If you want the best of all worlds, you need to get a good
> SCSI Controller and some SCSI disks.
I'd pay $100 more for a good SCSI CDRW drive!
But they don't seem to be sold any more. Anybody know where I can
still buy a new SCSI CDRW drive?
John S.
On Wed, 26 Feb 2003, John W. M. Stevens wrote:
> On Wed, Feb 26, 2003 at 12:02:13PM -0500, Richard B. Johnson wrote:
> >
> > If you want the best of all worlds, you need to get a good
> > SCSI Controller and some SCSI disks.
>
> I'd pay $100 more for a good SCSI CDRW drive!
>
> But they don't seem to be sold any more. Anybody know where I can
> still buy a new SCSI CDRW drive?
>
> John S.
I just did a search on "SCSI CD/RW" and came up with 304,000
entries, the first several being "Plextor" "Plexwriter" (I have
two of them at home). Yamaha (I have one of them here at work).
They seem to be the major SCSI DC/RW vendors..."
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Wed, 2003-02-26 at 17:02, Richard B. Johnson wrote:
> This has turned out to be a FAQ. DMA is not "better"
> than some other transfer mode. It's just a method.
In the IDE world that isnt quite so. The IDE world has other
limits depending on PIO versus DMA setup which make your
explanation, while correct for the general case incorrect for
the IDE world.
DMA is a lot better than other transfer modes on IDE devices, not
only because PIO burns CPU but because of the cable timings.
IDE normally goes up to PIO4, PIO4 is equivalent to MWDMA2. IDE
DMA then goes up to UDMA133/150 with SATA. So PIO limits you to
a fair bit under 10Mbytes/second, while UDMA133 generally comes
down to your PCI bus capability.