No that should not make a difference.
The ide-dma code does/can not enable UDMA-3/4; therefore, it is not used.
Regardless of the setting of IDE_DMA_BLAH_BLAH......., the kernel
will/can not auto-enable dma.
The ide-dma code will enable UDMA based upon
drive->id->ultra_dma == 0x0407, mode 2
drive->id->ultra_dma == 0x0207, mode 1
drive->id->ultra_dma == 0x0107, mode 0
but other modes fail
drive->id->ultra_dma == 0x080F, mode 3
drive->id->ultra_dma == 0x101F, mode 4
I started to add generic UDMA modes 3/4 generic support, but the drives
are breaking the rules. I have to find another legal test to determine
the usablity. Since there is almost no difference in the chipset codes
for speed detection, and bit 13 of word93 is locked and not
enabled/disabled based on the capacitance test for the 80c cable and the
adapter verifing the enable via hardware; I have a MAJOR problem.
UGLY NOTE::
UDMA mode 4 == mode 2 plus a cable, same for 3/1.
If the test fails for correct communication speeds do to the BIOS crapping
out and dropping the ball. We are stuck for a while. I have found that
sum BIOSes envoke DMA at the hardware level, don't ask how, I have not
gotten there yet. 99% of the problem comes from the modified AGP
chipsets.
In short, there are chipsets that may be compatable with the latest
technology, but not functional. My WAG at the problem is that the
drive(s), chipset, BIOS combination are unusable. Of these, the BIOS is
the only real option to upgrade.
Did it ever boot? If we get to that point, I may be able to salvage a
solution, else, go by a Promise Ultra66 card.
Andre Hedrick
The Linux IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/