From: Michael Schmitz <schmitzmic@gmail.com>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: linux-m68k@vger.kernel.org, Tuomas Vainikka <tuomas.vainikka@aalto.fi>
Subject: Re: esp_scsi, was Re: Modified Linux 4.1.20 (mac+scsi) on Quadra 660av
Date: Wed, 9 Nov 2016 20:06:45 +1300 [thread overview]
Message-ID: <a72ead45-5b30-8ab8-aa2e-1b2404e7dc16@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1611022052170.12008@nippy.intranet>
Hi Finn,
got sidetracked once again ...
>> 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.
Who asserts ATN in case of reselection? I always thought that the
target, by initiating reselection, assumes the role of initiator and is
in charge of driving bus phase changes (including control of ATN).
>> 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.
So the initiator would have to read two tag message bytes if a target
reselects that had a tagged command disconnected? From the initiator
side, that should work (if an untagged commmand has been issued, no
tagged commands are sent so we expect either tagged or untagged
reselections).
>> 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.
Can't see how - reconnect_with_tag() is only used if no untagged command
is on record for the target.
>
>> 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).
Not sure we can get control lines read - bus phases are available IIRC.
> 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.
PIO does get set up for the expected number of message bytes though. Is
there a check for phase mismatch during PIO?
>>> 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.
The documentation mentions a command descriptor block to be transferred
- would only apply to ESP in target mode again.
> 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.
What ESP versions are used in the Quadras vs 660av?
Cheers,
Michael
next prev parent reply other threads:[~2016-11-09 7:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <579F54CA.7010009@yahoo.com>
[not found] ` <alpine.LNX.2.00.1608021112170.25032@nippy.intranet>
[not found] ` <57A0CACE.8060801@yahoo.com>
[not found] ` <alpine.LNX.2.00.1608031413180.2246@nippy.intranet>
[not found] ` <81b56e9c-21bf-09c1-6faa-2c79937b7557@gmail.com>
[not found] ` <alpine.LNX.2.00.1610281447190.29347@nippy.intranet>
[not found] ` <eab997b4-16be-2f63-1bc8-3d5030cc254e@gmail.com>
[not found] ` <alpine.LNX.2.00.1610301649530.22486@nippy.intranet>
[not found] ` <07619c3e-0786-cacf-9fcb-e32e5ed77a09@gmail.com>
[not found] ` <alpine.LNX.2.00.1611011012510.23137@nippy.intranet>
2016-11-01 7:00 ` esp_scsi, was Re: Modified Linux 4.1.20 (mac+scsi) on Quadra 660av Michael Schmitz
2016-11-01 22:10 ` Finn Thain
2016-11-02 7:18 ` Michael Schmitz
2016-11-02 9:53 ` Finn Thain
2016-11-09 7:06 ` Michael Schmitz [this message]
2016-11-09 7:26 ` Finn Thain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a72ead45-5b30-8ab8-aa2e-1b2404e7dc16@gmail.com \
--to=schmitzmic@gmail.com \
--cc=fthain@telegraphics.com.au \
--cc=linux-m68k@vger.kernel.org \
--cc=tuomas.vainikka@aalto.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox