Re: [PATCH] Serialize CMD643 and CMD646 to fix a hardware bug with SSD

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Friday 23 October 2009 20:22:50 Alan Cox wrote:
> >     Yeah. The libata driver however doesn't make use of that register, 
> > unlike  cmd64x. It doesn't even touch the interrupt bits on PCI0646, only 
> > manipulation the "old" bits on PCI-64[89].
> 
> Yes I purposefully left out all the complexity because when I tested the
> cards I had it simply wasn't needed. I'm also not sure we should merge
> anything from the old to the new one until we know why the old one
> corrupts and the new one merely gets upset. Accidentally porting over a
> corruptor would be very bad indeed.

Oh, we know that.

"Old" one corrupts because somebody thought it would be a smart move to remove
serialized flag instead of debugging certain problem properly..

"New" one gets serialized at the command issue level (like all other new shiny
libata PATA stuff) and this may as well explain the difference..

> >     It seems that I need to sync up these two, pata_cmd64x.c seems to be 
> > lagging behind the changes in cmd64x.c. Well, not only this one, at least 
> > pata_hpt* drivers are lagging behind too...

Just from the memory:

pata_sis, pata_atiixp, pata_it8213, pata_cs5536, pata_amd..

So, gentlemen, when are you planning to remove IDE (not from your playground
Linux distribution but from kernel.org)?

I've heard that it will happen "soon" 4 years ago... :)

> That would be useful - although several of the differences are because
> the pata_hpt driver took from the vendor supplied reference code not the
> old IDE code. It also seems more stable for having done that.

Yeah, right..

This reminds me of that hpt366 blacklist that somebody forgot to port over
initially and which resulted in real world data corruptions..

-- 
Bartlomiej Zolnierkiewicz