On 09/11/2013 04:08 PM, Tuomas Vainikka wrote:
> On 09/11/2013 01:12 PM, Michael Schmitz wrote:
>> Hello Tuomas,
>>
>>>> That's the attitude - my suggestion was purely pragmatic, in order to
>>>> overcome that particular roadblock and see whether there's further
>>>> issues. But fixing this properly would be much preferred.
>>>>
>>>> David Miller is still maintainer of the ESP code - I can't think of
>>>> anyone better suited to answer ESP specific questions really.
>>>>
>>>> Cheers,
>>>>
>>>>     Michael
>>>>
>>> I got it to work. Somehow, at least. I wrote the driver to use PIO for
>>> command block reads and writes, and found out that it didn't fix the
>> Thanks, that does indeed absolve DMA.
>>
>>> problem. Using PIO, only the first byte of the tag message comes 
>>> through. It
>>> might not be esp_scsi's fault, but there seems to be an assumption 
>>> that all
>>> devices support TCQ. Also, no SCSI-2 features seem to be enabled in 
>>> the chip
>>> by esp_scsi.
>> I'd have to check with DaveM, but such an assumption might in fact 
>> exist.
>>
>> SCSI-2 features might have been disabled in response to your disk's
>> response in the device configure phase. Maybe someone with a newer
> In fact, the features are never enabled under any circumstance. But, 
> they only seem to add some functionality in how queue tag messages are 
> processed by the chip and not necessarily forbid the functionality if 
> not used.
>> SCSI disk (one that does support TCQ from scratch, and the full SCSI-2
>> command set or better) should try the original driver sometime.
>>
>> What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
>> higher? (Apologies for asking this - it will be in one of your old
>> logs but I cannot easily read these here.)
>>
> The drive you would find by searching with the model number in the 
> logs would point you to an IDE drive, which is actually connected to a 
> bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI 
> features. I also have a 'real' ST51080N that supports Fast SCSI-2 that 
> I've also tested with the driver to no avail. I will double check 
> again with the real SCSI drive to ascertain that the bridge adapter is 
> not the culprit, just to make sure.
>
The driver without the slave_configure hack fails with the same IRQ2 
timeout when the ST51080N hdd is used (see zesp164_orig_slave_cfg.cap).
When the hack is enabled, the hdd works like a charm; none of the 
aforementioned messages (wrong page, write again) are produced (and the 
speed is nearly acceptable :-) ) (see zesp165_hacked_slave_cfg.cap).

-Tuomas