Re: m68k v3.16 status update

[Michael Schmitz <schmitzmic@gmail.com>]

Tuomas,

are you still in the position to test tagged queue messages on Zorro ESP
hardware?

I've modified the Zorro ESP driver based on the work Finn Thain did for
the Mac ESP driver (handling message in transfer by PIO, with special
handshaking provisions for the message in case) and tried to test this
on elgar (CyberStorm I ESP) but the original bug does not show up there.
Might be to do with the SCSI disk used, or the CyberStorm I board.

Might be better to test the new code on your hardware where we know the
bug happened in the first place.

Cheers,

	Michael

Am 09.08.2014 um 18:45 schrieb Tuomas Vainikka:
> On 09.08.2014 01:25, Michael Schmitz wrote:
>> Hi Tuomas,
>>>>
>>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM
>>>> suggested a change to enable SCSI-2 features to help with extended
>>>> message bytes but that did not work as intended. Haven't had time to
>>>> follow that one up. Tuomas' fix to the driver to bypass DMA for
>>>> message in works OK though - do you want it submitted back to
>>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>>
>>>>
>>> Just to refresh your memory, the final fix was not to bypass DMA at
>>> any level (I did that for the command transfer, but that didn't
>>> help), but to have a dedicated slave_configure() function in the
>>> Amiga Zorro ESP driver that would not enable TCQ.
>>
>> You guessed right about memory failing me - it wasn't about DMA in the
>> end (for some reason, I seem to have DMA stuck in my mind at the
>> moment), Do you see any other avenues to try and enable tagged
>> commands in the ESP chip? We tried one config register only so far...
>>
> I think I've tested almost all possible register settings for the chip,
> but it occurred to me that it is not enough to enable some chip features
> by flipping bits. The code in esp_scsi would need to be modified to
> handle the behaviour of these enabled features also.
> 
> So, rethinking the code in esp_scsi would be one option.
> 
> The second possibility is that I have a buggy chip in my setup. Removing
> a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
> There are different versions of the SCSI-boards out there with different
> chips; NCR, AMD, and QLogic, so if we had more people testing the driver
> we would find out if the chip is actually the problem. (Is anyone even
> testing the ISA/PCI cards that use esp_scsi?)
> 
> Those are my suggestions at the TCQ problem.
> 
> But do we really need TCQ?
> 
> -Tuomas