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

Attachment: zesp164_orig_slave_cfg.cap.gz
Description: GNU Zip compressed data

Attachment: zesp165_hacked_slave_cfg.cap.gz
Description: GNU Zip compressed data

Reply via email to