Wed, 2 Nov 2016 20:53:50 +1100 (AEDT)
On Wed, 2 Nov 2016, Michael Schmitz wrote:
The complication is that the spec demands that certain messages be
acknowleged with /ATN negated before the final negation of /ACK. I
think that negating /ACK with /ATN asserted signals message rejection.
Yep, that's my reading as well.
Perhaps that's the problem here: scsi_esp_cmd(esp, ESP_CMD_SATN)
occurs after the transfer,
Where? In esp_reconnect, we don't get to that point when returning from
esp_reconnect_with_tag() after timeout.
Well, the point is, we potentially release ACK (either after the
Information Transfer command or after the Accept Message command) with ATN
still asserted.
And without timeout, there's still the check for ESP_CMD_FLAG_ABORT
which I don't see set anywhere.
I don't know what that's about. The git history may explain where it comes
from.
but instead probably should be scsi_esp_cmd(esp, ESP_CMD_RATN) before
scsi_esp_cmd(esp, ESP_CMD_MOK). It would be easy to believe that some
targets don't tolerate this.
Anyway, I suspect our problem lies in this reselection message
transfer, not in the configuration registers.
How does the target signal end of message in phase? Stop handshaking, or
change phase?
Either would do. To stop handshaking would imply entering bus free phase.
ATN going false?
AIUI, only the initiator can drive ATN.
With the DMA programmed for two tag bytes, and the reselection
originating from a tagged command, I would expect the target to send the
two tag bytes.
Sure, but I think the initator is messing it up along the way.
Would it help to do the message transfer without DMA?
I would, just to see more clearly what was going on (command queue,
control lines, bus phase).
Recall that Tuomas said he tried PIO for this with zorro_esp without any
improvement. And I first saw this bug on a Quadra 660av, on which mac_esp
uses PIO for all transfers.
Anyway, there must about 3 potential patches from this discussion. I
say we do as Geert suggests and move the discussion to the
kernel.org lists (with code, of course).
Agreed - the three patches I see so far would be
- set config2 SCSI2 enable bit as originally proposed by Dave,
- correct the esp_reset_cleanup() bug so a reset won't wipe out our
config3 ESP_CONFIG3_TBMS and ESP_CONFIG3_GTM bits
- set ESP_CONFIG3_TBMS and ESP_CONFIG3_GTM for all targets in either
esp_slave_configure() or esp_reset_esp()
Is that what you had in mind?
Something like that. All of which is based on the notion that the
config2 SCSI2 Enable bit could be useful for an initiator. But that
notion looks more and more dubious to me --
What use could an initiator have for the Group Two Command Block bit
(ESP_CONFIG3_GTM)?
Upon closer reading of the docs, none.
What use could an initiator have for the QTAG Control bit
(ESP_CONFIG3_TBMS) when the target never controls /ATN? (I only
remembered this yesterday, so please ignore my earlier comments about
reselection and SEL-with-ATN.)
I had thought the reselection process similar to selection. But if the
target does not signal further message bytes by keepin ATN asserted,
that bit might not matter here.
If only the initator drives ATN, the documentation can only be referring
to an ESP device in target mode.
Are we dealing with SCSI disks that fool the domain validation into
assuming tagged queuing capability, and then ignore the tag message
bytes, sending only the identify message byte on reselection?
I don't think so.
Trying to make reconnect_with_tag work for these disks would be foolish
indeed ...
My recollection from 2009 is that this particular disk did work with
mac_esp on one of my Quadras, but not on my 660av. And three people have
reported the problem now (to my knowledge) so I don't blame the disks.
--
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
