Now I have a strange situation. I finally got the dvd-rom and cd burner
devices to be recognized at all under 2.6.1 and now they work but DMA seems to
be off.
The situation: Asus P4P800 motherboard with Intel ICH5 chipset in Enhanced
mode "SATA Only". Using 2.6.1 with ata_piix handling the two SATA hard drives
(sda, sdb) and ide-cdrom handling the PATA drive, cd burner, and dvd (hda,
hdc, hdd).
When I play DVDs using Xine it seems to be barely able to keep up and
occasionally stutters. Much as if DMA were disabled. And indeed I see it
apparently isn't.
Moreoever when I try to turn it on I get EPERM. And I don't see the kernel
option to use DMA by default any more. I suppose that went out with 2.6.1?
bash-2.05b# hdparm -v /dev/hdd
/dev/hdd:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 1 (on)
readahead = 256 (on)
HDIO_GETGEO failed: Invalid argument
bash-2.05b# hdparm -d 1 /dev/hdd
/dev/hdd:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)
bash-2.05b# hdparm -I /dev/hdd
/dev/hdd:
ATAPI CD-ROM, with removable media
Model Number: LG DVD-ROM DRD-8160B
Serial Number:
Firmware Revision: 1.01
Standards:
Used: ATAPI for CD-ROMs, SFF-8020i, r2.5
Supported: CD-ROM ATAPI-2
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=150ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=227ns IORDY flow control=120ns
bash-2.05b# hdparm -i /dev/hdd
/dev/hdd:
Model=LG DVD-ROM DRD-8160B, FwRev=1.01, SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:150}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
* signifies the current active mode
--
greg
> /dev/hdd:
> setting using_dma to 1 (on)
> HDIO_SET_DMA failed: Operation not permitted
> using_dma = 0 (off)
>
-EPERM is usually caused by not having your chipset compiled into the kernel
or the chipset driver not supporting DMA.
If the first is the case, try compiling in one or more chipsets you suspect
are yours in Device Drivers->Char->(ALI Chipset support, ATI Chipset support
etc.) and Device Drivers->ATA/ATAPI->(ALI Chipset support, AMD Chipset
support) etc. etc. Find your chipsets and compile them into the kernel.
If its the second case I have no idea if a particular driver isnt supporting
DMA. AFAIK they all should. Thats a question for that particular chipset
maintainer.
However your problem is most certainly the first. It escapes me which device
section will solve your problem (CHAR or ATA/ATAPI) but try both, it won't
hurt to have some un-used code in the kernel. You can always remove un-needed
drivers when you pinpoint the driver you need.
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------
Eric <[email protected]> writes:
> If the first is the case, try compiling in one or more chipsets you suspect
> are yours in Device Drivers->Char->(ALI Chipset support, ATI Chipset support
> etc.) and Device Drivers->ATA/ATAPI->(ALI Chipset support, AMD Chipset
> support) etc. etc. Find your chipsets and compile them into the kernel.
Ooh. The thing that had me confused was that the chipsets are under "PCI IDE
chipset support". But it seems it was always under that heading, even in 2.4.
So I'm not sure how I missed that.
> However your problem is most certainly the first. It escapes me which device
> section will solve your problem (CHAR or ATA/ATAPI) but try both, it won't
> hurt to have some un-used code in the kernel. You can always remove un-needed
> drivers when you pinpoint the driver you need.
I had all the IDE stuff disabled when I was trying to eliminate variables that
could cause the scsi ata_piix driver to fail. Then missed this subpanel when I
was turning stuff back on.
Thanks for the help.
--
greg