Re: ata_std_qc_defer not good enough for FIS-based switching ?

[Mark Lord <liml@rtr.ca>]

Tejun Heo wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>>> Mark Lord wrote:
>>>> Mmm.. I just plugged the same PM + drives into my sata_sil24 card here,
>>>> and that driver went bonkers when I did the same test.
>>>>
>>>> Had to reboot eventually to recover.
>>>
>>> Hmm... That can't be.  Above all, although we do manual scheduling 
>>> around sil24, the controller does its own scheduling and will happily 
>>> issue command in the right order even if the software scheduler 
>>> screws up.  Do you have the log?
>> ..
>>
>> Here's what was in /var/log/messages after I held the power button
>> for five seconds to force a poweroff and then rebooted.  I didn't make 
>> much
>> effort to learn more, as I'm already busy enough testing/debugging 
>> sata_mv.
> 
> Hmmm... Have been testing NCQ + non-NCQ heavy load test w/ deadline 
> scheduler for 30+ mins now and there's no problem at all.  I'm pretty 
> sure sata_sil24 can handle mixed (across different drives) NCQ + non-NCQ 
> workload okay.
> 
> One catch w/ sata_sil24 is that it has something called PMP DMA CS 
> errata which means that all context is lost if any error (including a 
> device one) occurs during commands are pending to more than two devices 
> behind a port, the controller's state gets completely corrupt, so when 
> something goes wrong while lots of commands are pending via PMP, it's 
> often impossible what exactly went wrong.
> 
> sil4726/3726 also has a quirk.  It has configuration device as the last 
> device and issuing random IOs it might cause unpredictable results.  So, 
> can you please re-try the test excluding the pseudo config device?
..

Yeah, I'll retest it Right Now.  :)

At the moment, I have the Sil PM plugged in, and it all behaves nicely.
The previous failure was with the Marvell PM, so I'll hook that up next
and retest with it.

Cheers