booting fail on PATA disks using AHCI capable chipsets?
|Reported by:||rudolfc||Owned by:||marcusoverhagen|
On my ASUS P5E3 sits a Marvell 88SE6111 PATA/SATA controller with one ultra DMA 100/133 connector, and one external SATA3.0 Gb/s port (sata on the go).
DMA fails on this chipset using the IDE busmanager, and reading and writing from/to disk both fail using 32bit PIO access (IDE and ATA busmanager). Both reading and writing succeed in 16bit PIO access.
I've been reading the net a bit, and from the looks of it this chip is a AHCI mimicking chipset. It would be able to run in AHCI mode even for the PATA bus, but it can also run in 'legacy' mode.
I get the feeling that the chip has to be 'told' to use legacy mode by accessing certain registers in a certain way/order. Looks like it's done here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/ata/pata_marvell.c
in routine: marvell_pre_reset();
So I guess something like this has to be done somewhere in a driver, or we should run this controller in AHCI mode for the PATA port. I expect (guess) that 32bit PIO I/O and DMA would work with the marvell_pre_reset() trick.???
Since Revision: R27884 the use of this adapter works in 16-bit PIO mode as the driver generic/ide_adapter has been modified to always use 16bit transfers for reading and writing in PIO mode.
This is a workaround until the ata (and ide) busmanagers can automatically fall-back from 32bit PIO mode to 16bit PIO mode on 32bit trouble (for the writing instance: no int after writing, but a timeout occurs).
(Note: I forced 16-bit writing in R27884, 16-bit reading was already forced ever since the driver was imported in svn over 4 years ago! I did test 32bit reading tough and it indeed failed.)
I tested different harddisks, all failed.
Hopefully I am making sense..