booting fail on PATA disks using AHCI capable chipsets?

[rudolfc]

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..

Greetings!

Rudolf.

[rudolfc]

Oh,

The ATA busmanager quits this way (on writing): -it (thinks it) sends all sectors it should, so repeatedly sectors are written code-wise. -after it completed writing (it thinks), it waits for drq_down, but fails: ata_exec_pio_transfer:ata_wait_for_drqdown failed ata_exec_pio_transfer:error

[scottmc]

Do you still have access to the hardware? Can you retest with a more recent build of Haiku?

[rudolfc]

I still have access to the hardware, but it works as stated above, by forcing 16 bit read and write mode. AFAIK no-one extended stuff here so it's still as it is. Since booting succeeds one _could_ close this ticket..

Rudolf.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed