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

[Mikulas Patocka <mpatocka@redhat.com>]

> Right, and see also:
> 
> commit 6b5cde3629701258004b94cde75dd1089b556b02
> Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date:   Mon Dec 29 20:27:32 2008 +0100
> 
>     cmd64x: set IDE_HFLAG_SERIALIZE explictly for CMD646
> 
> Which is how we got there.
> 
> The most conservative thing to do is to set the flag as
> is done by mpatocka's patch but I'd like Frans to regression
> test that on his ultra5.
> 
> Frans can you do that?
> 
> Thanks.

I read the thread about wild interrupts that Frans was observing and that 
led to disabling the serialization.

The thing is tricky --- if we read status register on interrupt, we break 
the serialization principle and introduce potential data corruption.

If we don't read the status register, the wild interrupt kills the whole 
interrupt line.

I think the interrupt handler should read the BM-status register on both 
channels (it reflects the interrupt state even in PIO mode) to test if 
there is an unexpected interrupt on the inactive channel --- this should 
be much more safe than reading the status register. If there is an 
interrupt, then
--- read the status of the inactive channel? (potential data corruption, 
but it is reported to happen only on boot).
--- Or can the interrupt be acknowledged only in BM-status without 
touching the device? I believe yes, it shoud shut the PCI interrupt but it 
would leave the IDE interrupt line on (should be cleared on next command).

Mikulas