Hi there!

I'm currently trying to write a cloning software that use udma. I'm able to program the bus master to perform the transfer (on a vt6421a raid pci adapter). Everything works fine with sata, but with pata it's a different story. I get like 20% of the transactions ending up with crc errors. It seems to be related to the harddisk make (toshiba is 1/255 error, seagate and wd 20-40/255). It doesn't seem related to the type of pata to sata convertor or the cable. The timings on the hdd and the adapter were correctly programmed. I really need pata transfert as i would like to implement a hardware reset.
My questions are for those who have an experience in this type of programming:
-Is it normal to have such a high percentage of errors?
-Could it be related to the adapter (the via was chosen for the datasheet availability)
-How these errors must be handled? Repeat the 0x25 command until the transfert ends normally or ...

Thank you

In my experience with other PATA implementations, no.

You say that the percentage of I/O with CRC errors varies between HDD makes. This is typical behaviour for signal quality issues, so I suggest to investigate your "physical layer" electronics. If you are using SATA/PATA converters, then issues on the SATA link to a converter need to be considered, as well as issues on the PATA link itself. I can't sensibly give more detailed suggestions without having the config on a test bench in front of me.

Do you connect SATA directly to PATA connector or use cable?

Using correct cable? Have you tried a slower UDMA speed?

_________________
All went well until I plugged the drive in.

@Vorian: My thoughts about the SATA link above can probably be ignored, because if I understand you correctly, you are seeing different error rates with different PATA drives (using a SATA/PATA converter) - I presume you didn't change anything SATA-related during those tests.

Edited to add:
@guru: Agreed - those are some of the indirect changes which could be made, to try to infer a physical layer problem, if more direct measurement (e.g. using a high-speed oscilloscope) can't be done by the OP.

Thank you for your answers.
In fact I only tested sata drives on the sata end of the adapter with no error at all.
The problems arised when i connected drives (pata and sata) to the pata end of the vt6421. until UDMA33 they were no errors, above UDMA33 error rates varies from 1/255 (for a toshiba drive) to 20-40/255(for 2 seagates, 2wd and a samsung). I used the pata to sata convertor from my salvationdata dr (jmicron) and a 80 cable. I also tested another cheap converter, i changed the cable all these combinations gave the same error rate, so that left me with a/ bad pci adapter, b/ normal errors rate, c/?
I really doubted about b/ but I wanted to ask here to be sure. I'm gonna try another adapter...
@Vulcan: I have a 250mhz dso. Unfortunately it's a bit low to diagnose hardware problems on the ide bus.

Based on these comments, I now see how the initial posting was ambiguous about exactly what was being connected where - I thought you first said everything was OK using SATA.

I'm too confused with the ambiguous descriptions, for it to be sensible making further comments or spending time on analysis Much clearer descriptions / photos / test scenarios & results are needed IMHO, to avoid wasted time & misunderstandings.

P.S. Even with limited bandwidth DSO, that doesn't mean the results of comparisons with "known good" are useless

Good luck!

I had some strange issues with SATA error rates in the past and a firmware update fixed the problem.


It's rather tricky if your making your own driver. I had quite good luck with HIGHPOINT cards in the past and docs can be found.


Linux drivers can help you grasp how to poke at the cards :O)

_________________
All went well until I plugged the drive in.

It's seems I was not very clear, maybe I need to improve the way i write in English. Sorry for that, It's not my native language. Anyway, I found the error sources. I booted my computer using a msdos usb drive that wrote every packet read using the 0x25 command. When I didn't write these packets to usb drive, there were no crc errors. So I disabled usb and everything ran smoothly. Maybe a shared irq? I need to investigate further.
Thanks Vulcan and Guru for your advices