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
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.)
To cut the long story short, I hardwired TCQ off with a replacement function
for esp_slave_configure().
The replacement function resides in zorro_esp.c and is essentially doing the
same thing as the original if ESP_DEFAULT_TAGS was set to zero in
esp_scsi.h.
There is no need for PIO with the above hack.
That's a good start - now can anyone remember whether the old Zorro
ESP drivers ever used or supported tagged commands? I would not want
to hassle DaveM for something that never worked before.
If we can find out how to detect that TCQ is unsupported, Dave could
splice that into the core esp_slave_configure() and solve our problem.
I've attached a log of the module loading and some operations on the
attached hdd. Note that there are messages such as
[ 4627.040000] sd 0:0:0:0: [sda] Got wrong page
and
[ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.
WRITE SAME might be unsupported by your device (guessing, I could not
find out where the message originates from). The 'got wrong page' I
had to look up, but it also appears to be a case of unsupported
feature.
which don't seem normal.
The acid test is - did it destroy your filesystem?
If not, I'd say you did brilliantly.
Thanks again,
Michael
On Tue, Sep 10, 2013 at 11:13 PM, Tuomas Vainikka
<tuomas.vainikka@xxxxxxxx> wrote:
On 08/22/2013 11:34 PM, Michael Schmitz wrote:
Hello Tuomas,
No idea which functions you refer to regarding PIO (reading from FIFO).
Anyway, the DMA will read from the same FIFO that the CPU would, if I
understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
I suppose this is because reconnect_with_tag() cannot rely on the tag
information already being in the FIFO when it is called from
esp_reconnect(). esp_reconnect() is called from the reselection
interrupt so the fifo data is already present.
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
explains why the bytes might end up in FIFO; The chip DMA got disabled at
some point. Also, you need to explicitly issue a specific (don't know
which,
yet) command to let the DMA access the FIFO.
The chip DMA should be activated by the ESP_CMD_DMA bit that is set in
all uses of send_dma_cmd. I can't see where the DMA would have been
disabled.
The DMA transfer function can be changed to fetch less than seven bytes
from the FIFO by PIO instead of setting up DMA transfer (just poll the
FIFO
after sending the command to the ESP, instead of first setting up the
DMA
then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to
PIO. It is also possible that the chip interrupt is cleared prematurely
by
reading the interrupt register, in which case the interrupt is not seen
by
The Loop.
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
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.
To cut the long story short, I hardwired TCQ off with a replacement function
for esp_slave_configure().
The replacement function resides in zorro_esp.c and is essentially doing the
same thing as the original if ESP_DEFAULT_TAGS was set to zero in
esp_scsi.h.
There is no need for PIO with the above hack.
I've attached a log of the module loading and some operations on the
attached hdd. Note that there are messages such as
[ 4627.040000] sd 0:0:0:0: [sda] Got wrong page
and
[ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.
which don't seem normal.
-Tuomas
--
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
