[...]
> Now the kernel I am using I compiled myself and I selected to use DMA
> when available. Here is part of the kernel config:
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_BLK_DEV_ADMA=y
> # CONFIG_BLK_DEV_OFFBOARD is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_BLK_DEV_IDEDMA=y
>
> Now when I check with hdparm I get:
> # hdparm /dev/hda
>
> /dev/hda:
> multcount = 0 (off)
> I/O support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 0 (off)
> keepsettings = 0 (off)
> nowerr = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 77545/16/63, sectors = 78165360, start = 0
> busstate = 1 (on)
>
> So it seems it is not on?
I've noticed the same behavior with one of my extra ide-cards, a Promise
Ultra100 TX2 (does 'pdc20268' as chipset make sense, can't remeber).
The other card (a hpt366 based IWill <something>) as well as the
onboard (intel something i think) works fine though, so the behavior
seems to be chip dependent.
[...]
> But rechecking to see if changes have worked:
> hdparm /dev/hda
> give exactly the same output as above. Rechecking the speeds and these
> are the same too.
>
> I guess it is turned on already and the drives won't tell hdparm, or it
> can't be turned on anyway.
Hmm, if you try to turn it OFF, does the output from 'hdparm /dev/hda'
change?
I really have no idea what to do when hdparm fails, sorry.
Sincerely,
Emil
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
