On 09/11/2013 04:08 PM, Tuomas Vainikka wrote:
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).On 09/11/2013 01:12 PM, Michael Schmitz wrote: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.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, MichaelI 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 theThanks, 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 chipI'd have to check with DaveM, but such an assumption might in fact exist.by esp_scsi.SCSI-2 features might have been disabled in response to your disk's response in the device configure phase. Maybe someone with a newerThe 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.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.)
-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
