linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)
       [not found]                               ` <CAMuHMdUH=9sv-Vb3ZTAGyfvEQOO0x0x1cUYhfd7040k8d+bSYg@mail.gmail.com>
@ 2013-09-12 15:36                                 ` Tuomas Vainikka
  2013-09-26 13:50                                   ` Michael Schmitz
  2014-04-04 20:28                                   ` esp_scsi QTAG in FAS216 David Miller
  0 siblings, 2 replies; 23+ messages in thread
From: Tuomas Vainikka @ 2013-09-12 15:36 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Michael Schmitz, Linux/m68k, linux-scsi, David Miller

On 09/11/2013 05:48 PM, Geert Uytterhoeven wrote:
> On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> 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.
> BTW, it would be nice to start CCing linux-scsi@vger.kernel.org and
> David S. Miller <davem@davemloft.net> on future discussions.
>
> Gr{oetje,eeting}s,
>
>                          Geert
>
>
Hello,

Does anyone have the register descriptions for the FAS216 chip? It would 
seem that receiving only one byte during reconnect is perfectly normal 
[1] unless SCSI-2 features are explicitly enabled (which esp_scsi 
doesn't seem to be doing).

Also, looking at the timeout formulae in the old NCR53C9x.c driver, the 
values would be different for FAS216. Why was this dropped from the 
modern esp_scsi?

1. Page 2 in http://www.datasheetarchive.com/dl/Scans-030/ScansU9X12569.pdf

-Tuomas

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)
  2013-09-12 15:36                                 ` esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver) Tuomas Vainikka
@ 2013-09-26 13:50                                   ` Michael Schmitz
  2014-04-04 20:28                                   ` esp_scsi QTAG in FAS216 David Miller
  1 sibling, 0 replies; 23+ messages in thread
From: Michael Schmitz @ 2013-09-26 13:50 UTC (permalink / raw)
  To: Tuomas Vainikka; +Cc: Geert Uytterhoeven, Linux/m68k, David Miller, linux-scsi

Tuomas,

I might still have a copy of the manual somewhere from way back, if you 
haven't found it anywhere. Would be on an old disk or even hardcopy in 
storage, so please confirm you still need it.

Cheers,

  Michael



Am 13.09.2013 um 03:36 schrieb Tuomas Vainikka:

> On 09/11/2013 05:48 PM, Geert Uytterhoeven wrote:
>> On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz 
>> <schmitzmic@gmail.com> wrote:
>>>> 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.
>> BTW, it would be nice to start CCing linux-scsi@vger.kernel.org and
>> David S. Miller <davem@davemloft.net> on future discussions.
>>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>>
> Hello,
>
> Does anyone have the register descriptions for the FAS216 chip? It 
> would seem that receiving only one byte during reconnect is perfectly 
> normal [1] unless SCSI-2 features are explicitly enabled (which 
> esp_scsi doesn't seem to be doing).
>
> Also, looking at the timeout formulae in the old NCR53C9x.c driver, 
> the values would be different for FAS216. Why was this dropped from 
> the modern esp_scsi?
>
> 1. Page 2 in 
> http://www.datasheetarchive.com/dl/Scans-030/ScansU9X12569.pdf
>
> -Tuomas

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2013-09-12 15:36                                 ` esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver) Tuomas Vainikka
  2013-09-26 13:50                                   ` Michael Schmitz
@ 2014-04-04 20:28                                   ` David Miller
  2014-04-06 20:33                                     ` Michael Schmitz
  1 sibling, 1 reply; 23+ messages in thread
From: David Miller @ 2014-04-04 20:28 UTC (permalink / raw)
  To: tuomas.vainikka; +Cc: geert, schmitzmic, linux-m68k, linux-scsi

From: Tuomas Vainikka <tuomas.vainikka@aalto.fi>
Date: Thu, 12 Sep 2013 18:36:09 +0300

> Does anyone have the register descriptions for the FAS216 chip? It
> would seem that receiving only one byte during reconnect is perfectly
> normal [1] unless SCSI-2 features are explicitly enabled (which
> esp_scsi doesn't seem to be doing).

This is quite possibly true.  I've never see it happen myself while
testing the driver though.

> Also, looking at the timeout formulae in the old NCR53C9x.c driver,
> the values would be different for FAS216. Why was this dropped from
> the modern esp_scsi?

I've never seen a formula for any ESP or FAS chip for the timeout
other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192
factor being used in the old NCR53C9x driver.

I wrote esp_scsi.c based upon the old sparc ESP driver and the docs
I had available to me.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-04 20:28                                   ` esp_scsi QTAG in FAS216 David Miller
@ 2014-04-06 20:33                                     ` Michael Schmitz
  2014-04-07  3:39                                       ` David Miller
  2014-04-10 14:31                                       ` Kars de Jong
  0 siblings, 2 replies; 23+ messages in thread
From: Michael Schmitz @ 2014-04-06 20:33 UTC (permalink / raw)
  To: David Miller
  Cc: Tuomas Vainikka, Geert Uytterhoeven, Linux/m68k, linux-scsi,
	jongk

Hello Dave, Tuomas,

>> Also, looking at the timeout formulae in the old NCR53C9x.c driver,
>> the values would be different for FAS216. Why was this dropped from
>> the modern esp_scsi?
>
> I've never seen a formula for any ESP or FAS chip for the timeout
> other than the one mentioned in huge comment in
> esp_set_clock_params(), although I do see the 7668 instead of 8192
> factor being used in the old NCR53C9x driver.

I haven't gone far enough back in the 53C9x revision history to be
certain. but it would seem to me that Kars de Jong added that FAS
special case.

Can you confirm that, Kars? Any recollection as to the reason?

Cheers,

  Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-06 20:33                                     ` Michael Schmitz
@ 2014-04-07  3:39                                       ` David Miller
  2014-04-10 14:31                                       ` Kars de Jong
  1 sibling, 0 replies; 23+ messages in thread
From: David Miller @ 2014-04-07  3:39 UTC (permalink / raw)
  To: schmitzmic; +Cc: tuomas.vainikka, geert, linux-m68k, linux-scsi, jongk

From: Michael Schmitz <schmitzmic@gmail.com>
Date: Mon, 7 Apr 2014 08:33:12 +1200

> Hello Dave, Tuomas,
> 
>>> Also, looking at the timeout formulae in the old NCR53C9x.c driver,
>>> the values would be different for FAS216. Why was this dropped from
>>> the modern esp_scsi?
>>
>> I've never seen a formula for any ESP or FAS chip for the timeout
>> other than the one mentioned in huge comment in
>> esp_set_clock_params(), although I do see the 7668 instead of 8192
>> factor being used in the old NCR53C9x driver.
> 
> I haven't gone far enough back in the 53C9x revision history to be
> certain. but it would seem to me that Kars de Jong added that FAS
> special case.
> 
> Can you confirm that, Kars? Any recollection as to the reason?

Just as another reference point, I looked at the FreeBSD 'esp' driver
and it also uses the 8192 factor for all chips, including FAS216.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-06 20:33                                     ` Michael Schmitz
  2014-04-07  3:39                                       ` David Miller
@ 2014-04-10 14:31                                       ` Kars de Jong
  2014-04-11  1:47                                         ` Michael Schmitz
  1 sibling, 1 reply; 23+ messages in thread
From: Kars de Jong @ 2014-04-10 14:31 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: David Miller, Tuomas Vainikka, Geert Uytterhoeven, Linux/m68k,
	linux-scsi

2014-04-06 22:33 GMT+02:00 Michael Schmitz <schmitzmic@gmail.com>:
>
> Hello Dave, Tuomas,
>
> >> Also, looking at the timeout formulae in the old NCR53C9x.c driver,
> >> the values would be different for FAS216. Why was this dropped from
> >> the modern esp_scsi?
> >
> > I've never seen a formula for any ESP or FAS chip for the timeout
> > other than the one mentioned in huge comment in
> > esp_set_clock_params(), although I do see the 7668 instead of 8192
> > factor being used in the old NCR53C9x driver.
>
> I haven't gone far enough back in the 53C9x revision history to be
> certain. but it would seem to me that Kars de Jong added that FAS
> special case.
>
> Can you confirm that, Kars? Any recollection as to the reason?

That is the value that's in the data manual of the Symbios Logic
SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller).

Funny, according to the QLogic FAS2x6 manual the value should be 7682
for FAS216/216U/236/236U chips...

I don't think it's all that important. It only means that the actual
selection timeout used by the chip will be slightly shorter than it is
supposed to be.


Kind regards,

Kars.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-10 14:31                                       ` Kars de Jong
@ 2014-04-11  1:47                                         ` Michael Schmitz
  2014-04-13 14:47                                           ` Kars de Jong
  0 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2014-04-11  1:47 UTC (permalink / raw)
  To: Kars de Jong
  Cc: David Miller, Tuomas Vainikka, Geert Uytterhoeven, Linux/m68k,
	scsi

Hello Kars,


>> > I've never seen a formula for any ESP or FAS chip for the timeout
>> > other than the one mentioned in huge comment in
>> > esp_set_clock_params(), although I do see the 7668 instead of 8192
>> > factor being used in the old NCR53C9x driver.
>>
>> I haven't gone far enough back in the 53C9x revision history to be
>> certain. but it would seem to me that Kars de Jong added that FAS
>> special case.
>>
>> Can you confirm that, Kars? Any recollection as to the reason?
>
> That is the value that's in the data manual of the Symbios Logic
> SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller).
>
> Funny, according to the QLogic FAS2x6 manual the value should be 7682
> for FAS216/216U/236/236U chips...
>
> I don't think it's all that important. It only means that the actual
> selection timeout used by the chip will be slightly shorter than it is
> supposed to be.

Thanks for checking that - I agree that it might not amount to much.

The more important issue is the one about the one-byte reconnect
message. Does the manual speak to that particular issue? Any hint on
how we could enable SCSI-2 features on chip init?

Can you point me to a source for the manuals if possible?

Cheers,

  Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-11  1:47                                         ` Michael Schmitz
@ 2014-04-13 14:47                                           ` Kars de Jong
  2014-04-13 22:38                                             ` Michael Schmitz
  0 siblings, 1 reply; 23+ messages in thread
From: Kars de Jong @ 2014-04-13 14:47 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: David Miller, Tuomas Vainikka, Geert Uytterhoeven, Linux/m68k,
	scsi

Hi Michael,


2014-04-11 3:47 GMT+02:00 Michael Schmitz <schmitzmic@gmail.com>:
> The more important issue is the one about the one-byte reconnect
> message. Does the manual speak to that particular issue? Any hint on
> how we could enable SCSI-2 features on chip init?

There's the SCSI2 bit in the Config 2 register and/or the QTE bit in
the Config 3 register. The 53CF9x-2 manual says about SCSI-2 bit:

Bit 2 SCSI-2

Setting this bit allows the FSC to support two new features adopted in
SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2
commands. These features can also be set independently in the Config 3
register.

Tagged-Queueing
When this bit is set and the FSC is selected with ATN (Attention), it
will request either one or three message bytes depending on whether
ATN remains true or goes false. If ATN is still true after the first
byte has been received, the FSC may request two more message bytes
before switching to Command phase. If ATN goes false, it will switch
to Command phase after the first message byte. When the bit is not set
it will request a single message byte (as a target) when selected with
ATN, and abort the selection sequence (as an initiator) if the target
does not switch to Command phase after one message byte has been
transferred.

Group 2 Commands
(seems to only be relevant for target mode).

And about the QTE bit:

Bit 6 Queue Tag Enable

When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
The message bytes consist of a one-byte identify message and a
two-byte queue tag message. The middle byte is the tagged queue
message itself and the last byte is the tag value (0 to 255). When
this bit is set, the second byte is checked to see if it is a valid
queue tagging message. If the value of the byte is not 20, 21 or 22h,
the sequence halts and an interrupt is generated. When this bit is not
set, the chip aborts the Select With ATN sequence after it receives
one Identify Message byte, if ATN is still asserted.

Then there is a section called "Bus Initiated Reselection":

Bus Initiated Reselection
The FSC will allow itself to be reselected as an initiator by a target
if it has previously received the Enable Selection/Reselection
command. If the sequence completes normally, the following information
will be in the FIFO:

* Bus ID
* Identify Message
* Optional 2-byte queue tag message

The bus ID will always be present and will always be one byte. It is
an un-encoded version of the state of the bus during Reselection
phase.

The identify message will always be present and will always be one byte.

If queue tagging is enabled, and the target is sending a queue tag
message, the target will also send two queue tag message bytes.

> Can you point me to a source for the manuals if possible?

I only have dead tree versions of the QLogic manual and the Symbios
Logic manual.

The only public place I know of is bitsavers, they do have a manual
for the 53C94/95/96 online here:
http://bitsavers.trailing-edge.com/pdf/ncr/scsi/NCR_53C94_53C95_53C96_Data_Sheet_Feb90.pdf.

I put the 53C90A/B manual online at
http://members.home.nl/karsdejong/NCR53C90ab.pdf and a preliminary
version of the 53CF94/96-2 at
http://members.home.nl/karsdejong/NCR53CF9x-2.pdf.


Kind regards,

Kars.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-13 14:47                                           ` Kars de Jong
@ 2014-04-13 22:38                                             ` Michael Schmitz
  2014-04-14  2:14                                               ` David Miller
  0 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2014-04-13 22:38 UTC (permalink / raw)
  To: Kars de Jong
  Cc: David Miller, Tuomas Vainikka, Geert Uytterhoeven, Linux/m68k,
	scsi

Hi Kars,

thanks for the PDFs!

> Bit 2 SCSI-2
>
> Setting this bit allows the FSC to support two new features adopted in
> SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2
> commands. These features can also be set independently in the Config 3
> register.
>
> Tagged-Queueing
> When this bit is set and the FSC is selected with ATN (Attention), it
> will request either one or three message bytes depending on whether
> ATN remains true or goes false. If ATN is still true after the first
> byte has been received, the FSC may request two more message bytes
> before switching to Command phase. If ATN goes false, it will switch
> to Command phase after the first message byte. When the bit is not set
> it will request a single message byte (as a target) when selected with
> ATN, and abort the selection sequence (as an initiator) if the target
> does not switch to Command phase after one message byte has been
> transferred.

That appears to be our problem if I recall correctly Tuomas' debugging
report. (reselection, not selection as initiator). As
esp_slave_configure() enables queue tags regardless of chip config,
we'd best make certain the chip is configured correctly.

The SCSI2 bit is used to test for presence of config register 2 in
esp_get_revision but later cleared in the same function. It appears
we'd need to set it after the call to scsi_esp_register() - can you
test whether that obsoletes the zorro_esp_slave_configure hack,
Tuomas?

diff --git a/drivers/scsi/zorro_esp.c b/drivers/scsi/zorro_esp.c
index 1a1eb95..b33c3b5 100644
--- a/drivers/scsi/zorro_esp.c
+++ b/drivers/scsi/zorro_esp.c
@@ -418,9 +418,6 @@ static int zorro_esp_init_one(struct zorro_dev *z,
                return -EBUSY;
        }

-       /* Fill in the required pieces of hostdata */
-       scsi_esp_template.slave_configure = zorro_esp_slave_configure;
-
        host = scsi_host_alloc(tpnt, sizeof(struct esp));

        if (!host) {
@@ -508,6 +505,10 @@ static int zorro_esp_init_one(struct zorro_dev *z,
        if (err)
                goto fail_free_irq;

+       esp->config2 = ESP_CONFIG2_SCSI2ENAB;
+       zorro_esp_write8(esp, esp->config2, ESP_CFG2);
+
+
        zorro_set_drvdata(z, host);

        return 0;


> Group 2 Commands
> (seems to only be relevant for target mode).
>
> And about the QTE bit:
>
> Bit 6 Queue Tag Enable
>
> When this bit is set, the 53CF94/96 can receive 3-byte messages during
> bus-initiated Select With ATN. This feature is also enabled by setting
> bit 3 in the Configuration 2 register.

My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?

Cheers,

  Michael

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-13 22:38                                             ` Michael Schmitz
@ 2014-04-14  2:14                                               ` David Miller
  2014-04-14  5:05                                                 ` Tuomas Vainikka
                                                                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: David Miller @ 2014-04-14  2:14 UTC (permalink / raw)
  To: schmitzmic; +Cc: jongk, tuomas.vainikka, geert, linux-m68k, linux-scsi

From: Michael Schmitz <schmitzmic@gmail.com>
Date: Mon, 14 Apr 2014 10:38:09 +1200

> That appears to be our problem if I recall correctly Tuomas' debugging
> report. (reselection, not selection as initiator). As
> esp_slave_configure() enables queue tags regardless of chip config,
> we'd best make certain the chip is configured correctly.
> 
> The SCSI2 bit is used to test for presence of config register 2 in
> esp_get_revision but later cleared in the same function. It appears
> we'd need to set it after the call to scsi_esp_register() - can you
> test whether that obsoletes the zorro_esp_slave_configure hack,
> Tuomas?
 ...
>> Group 2 Commands
>> (seems to only be relevant for target mode).
>>
>> And about the QTE bit:
>>
>> Bit 6 Queue Tag Enable
>>
>> When this bit is set, the 53CF94/96 can receive 3-byte messages during
>> bus-initiated Select With ATN. This feature is also enabled by setting
>> bit 3 in the Configuration 2 register.
> 
> My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
> opinion, Dave?

As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode.  So it is not relevant for our discussion because this driver is
for initiator mode operation only.

But some pieces of documentation seem like they might not agree on
this point.

With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision.  As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.

But oddly in the NCR53CX docs:

	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt

it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.

Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.

Can we try testing the following patch?

====================
esp_scsi: Set SCSI2 bit in config2 register.

This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.

Reported-by: Kars de Jong <jongk@linux-m68k.org>
Reported-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
 		 */
 		esp->rev = ESP100;
 	} else {
-		esp->config2 = 0;
+		esp->config2 = ESP_CONFIG2_SCSI2ENAB;
 		esp_set_all_config3(esp, 5);
 		esp->prev_cfg3 = 5;
 		esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
 			} else {
 				esp->rev = ESP236;
 			}
-			esp->config2 = 0;
-			esp_write8(esp->config2, ESP_CFG2);
 		}
 	}
 }

^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-14  2:14                                               ` David Miller
@ 2014-04-14  5:05                                                 ` Tuomas Vainikka
  2014-04-14  8:51                                                   ` Michael Schmitz
  2014-04-14  9:01                                                 ` Michael Schmitz
  2016-10-28 21:54                                                 ` Finn Thain
  2 siblings, 1 reply; 23+ messages in thread
From: Tuomas Vainikka @ 2014-04-14  5:05 UTC (permalink / raw)
  To: David Miller, schmitzmic; +Cc: jongk, geert, linux-m68k, linux-scsi

On 14.04.2014 05:14, David Miller wrote:
> From: Michael Schmitz <schmitzmic@gmail.com>
> Date: Mon, 14 Apr 2014 10:38:09 +1200
>
>> That appears to be our problem if I recall correctly Tuomas' debugging
>> report. (reselection, not selection as initiator). As
>> esp_slave_configure() enables queue tags regardless of chip config,
>> we'd best make certain the chip is configured correctly.
>>
>> The SCSI2 bit is used to test for presence of config register 2 in
>> esp_get_revision but later cleared in the same function. It appears
>> we'd need to set it after the call to scsi_esp_register() - can you
>> test whether that obsoletes the zorro_esp_slave_configure hack,
>> Tuomas?
>   ...
>>> Group 2 Commands
>>> (seems to only be relevant for target mode).
>>>
>>> And about the QTE bit:
>>>
>>> Bit 6 Queue Tag Enable
>>>
>>> When this bit is set, the 53CF94/96 can receive 3-byte messages during
>>> bus-initiated Select With ATN. This feature is also enabled by setting
>>> bit 3 in the Configuration 2 register.
>> My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
>> opinion, Dave?
> As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
> (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
> mode.  So it is not relevant for our discussion because this driver is
> for initiator mode operation only.
>
> But some pieces of documentation seem like they might not agree on
> this point.
>
> With respect to bit 3 in the config3 register, it can take on one of
> two meaning depending upon chip revision.  As per ESP_CONFIG3_{TMS,FCLK}
> it either controls fast SCSI clocking, or it enabled 3 byte message
> recognition.
>
> But oddly in the NCR53CX docs:
>
> 	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
>
> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
> which enables both features.
>
> Again I looked at the FreeBSD driver and for all chips after plain
> esp100, they set ESP_CONFIG2_SCSI2ENAB.
>
> Can we try testing the following patch?
>
> ====================
> esp_scsi: Set SCSI2 bit in config2 register.
>
> This should allow proper recognition of 3 byte reselection
> on all esp100a and later chips.
>
> Reported-by: Kars de Jong <jongk@linux-m68k.org>
> Reported-by: Michael Schmitz <schmitzmic@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 55548dc..16f69e0 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
>   		 */
>   		esp->rev = ESP100;
>   	} else {
> -		esp->config2 = 0;
> +		esp->config2 = ESP_CONFIG2_SCSI2ENAB;
>   		esp_set_all_config3(esp, 5);
>   		esp->prev_cfg3 = 5;
>   		esp_write8(esp->config2, ESP_CFG2);
> @@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
>   			} else {
>   				esp->rev = ESP236;
>   			}
> -			esp->config2 = 0;
> -			esp_write8(esp->config2, ESP_CFG2);
>   		}
>   	}
>   }

I'll test these out soon.

Michael, where can I pull the latest version of zorro_esp?

-Tuomas

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-14  5:05                                                 ` Tuomas Vainikka
@ 2014-04-14  8:51                                                   ` Michael Schmitz
  2014-05-25  8:56                                                     ` Geert Uytterhoeven
  0 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2014-04-14  8:51 UTC (permalink / raw)
  To: Tuomas Vainikka; +Cc: linux-scsi, linux-m68k, David Miller, geert, jongk

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

Hi Tuomas,

>>> My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
>>> opinion, Dave?
>> As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
>> (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
>> mode.  So it is not relevant for our discussion because this driver is
>> for initiator mode operation only.
>>
>> But some pieces of documentation seem like they might not agree on
>> this point.
>>
>> With respect to bit 3 in the config3 register, it can take on one of
>> two meaning depending upon chip revision.  As per  
>> ESP_CONFIG3_{TMS,FCLK}
>> it either controls fast SCSI clocking, or it enabled 3 byte message
>> recognition.
>>
>> But oddly in the NCR53CX docs:
>>
>> 	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/ 
>> NCR53C9X.txt
>>
>> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
>> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
>> which enables both features.
>>
>> Again I looked at the FreeBSD driver and for all chips after plain
>> esp100, they set ESP_CONFIG2_SCSI2ENAB.
>>
>> Can we try testing the following patch?
>>
>> ====================
>> esp_scsi: Set SCSI2 bit in config2 register.
>>
>> This should allow proper recognition of 3 byte reselection
>> on all esp100a and later chips.
>>
>> Reported-by: Kars de Jong <jongk@linux-m68k.org>
>> Reported-by: Michael Schmitz <schmitzmic@gmail.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
>> index 55548dc..16f69e0 100644
>> --- a/drivers/scsi/esp_scsi.c
>> +++ b/drivers/scsi/esp_scsi.c
>> @@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
>>   		 */
>>   		esp->rev = ESP100;
>>   	} else {
>> -		esp->config2 = 0;
>> +		esp->config2 = ESP_CONFIG2_SCSI2ENAB;
>>   		esp_set_all_config3(esp, 5);
>>   		esp->prev_cfg3 = 5;
>>   		esp_write8(esp->config2, ESP_CFG2);
>> @@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
>>   			} else {
>>   				esp->rev = ESP236;
>>   			}
>> -			esp->config2 = 0;
>> -			esp_write8(esp->config2, ESP_CFG2);
>>   		}
>>   	}
>>   }
>
> I'll test these out soon.
>
> Michael, where can I pull the latest version of zorro_esp?
>

Not sure my patch had ever made it into Geert's m68k-queue - except for  
the patch in my previous mail, my zorro_esp.c is still the same as I  
got from you in October last year. The project has been on the back  
burner for too long ...

I'll look into setting up pull access to my repository. zorro_esp.c as  
of today attached for now.

Cheers,

	Michael



  

[-- Attachment #2: zorro_esp.c --]
[-- Type: text/plain, Size: 14808 bytes --]

/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
 *
 * Copyright (C) 1996 Jesper Skov (jskov@cygnus.co.uk)
 *
 * Copyright (C) 2011 Michael Schmitz (schmitz@debian.org) for 
 *               migration to ESP SCSI core
 */
/*
 * ZORRO bus code from:
 */
/*
 * Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux.
 *		Amiga MacroSystemUS WarpEngine SCSI controller.
 *		Amiga Technologies/DKB A4091 SCSI controller.
 *
 * Written 1997 by Alan Hourihane <alanh@fairlite.demon.co.uk>
 * plus modifications of the 53c7xx.c driver to support the Amiga.
 *
 * Rewritten to use 53c700.c by Kars de Jong <jongk@linux-m68k.org>
 */

#include <linux/module.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ratelimit.h>
#include <linux/dma-mapping.h>
#include <linux/scatterlist.h>
#include <linux/delay.h>
#include <linux/zorro.h>
#include <linux/slab.h>


#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/cacheflush.h>
#include <asm/amigahw.h>
#include <asm/amigaints.h>

#include <scsi/scsi_host.h>
#include <scsi/scsi_transport_spi.h>
#include <scsi/scsi_device.h>
#include <scsi/scsi_tcq.h>

#include "esp_scsi.h"

MODULE_AUTHOR("Michael Schmitz <schmitz@debian.org>");
MODULE_DESCRIPTION("Amiga Zorro NCR5C9x (ESP) driver");
MODULE_LICENSE("GPL");

#define DMA_WRITE 0x80000000

static struct zorro_driver_data {
	const char *name;
	unsigned long offset;
	unsigned long dma_offset;
	int absolute;
	int zorro3;	/* offset is absolute address */
} zorro_esp_driver_data[] = {
	{ .name = "CyberStormI", .offset = 0xf400, .dma_offset = 0xf800, .absolute = 0, .zorro3 = 0 },
	{ .name = "CyberStormII", .offset = 0x1ff03, .dma_offset = 0x1ff43, .absolute = 0, .zorro3 = 0 },
	{ .name = "Blizzard 2060", .offset = 0x1ff00, .dma_offset = 0x1ffe0, .absolute = 0, .zorro3 = 0 },
	{ .name = "Blizzard 1230", .offset = 0x8000, .dma_offset = 0x10000, .absolute = 0, .zorro3 = 0 },
	{ .name = "Blizzard 1230II", .offset = 0x10000, .dma_offset = 0x10021, .absolute = 0, .zorro3 = 0 },
	{ .name = "Fastlane", .offset = 0x1000001, .dma_offset = 0x1000041, .absolute = 0, .zorro3 = 1 },
	{ 0 }
};

static struct zorro_device_id zorro_esp_zorro_tbl[] = {
	{
		.id = ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM,
		.driver_data = (unsigned long)&zorro_esp_driver_data[0],
	},
	{
		.id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
		.driver_data = (unsigned long)&zorro_esp_driver_data[0],
	},
	{
		.id = ZORRO_PROD_PHASE5_CYBERSTORM_MK_II,
		.driver_data = (unsigned long)&zorro_esp_driver_data[1],
	},
	{
		.id = ZORRO_PROD_PHASE5_BLIZZARD_2060,
		.driver_data = (unsigned long)&zorro_esp_driver_data[2],
	},
	{
		.id = ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260,
		.driver_data = (unsigned long)&zorro_esp_driver_data[3],
	},
	{
		.id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
		.driver_data = (unsigned long)&zorro_esp_driver_data[4],
	},
	{ 0 }
};
MODULE_DEVICE_TABLE(zorro, zorro_esp_zorro_tbl);

struct blz1230_dma_registers {
        volatile unsigned char dma_addr;        /* DMA address      [0x0000] */
        unsigned char dmapad2[0x7fff];
        volatile unsigned char dma_latch;       /* DMA latch        [0x8000] */
};

struct blz2060_dma_registers {
	volatile unsigned char dma_led_ctrl;	/* DMA led control   [0x000] */
	unsigned char dmapad1[0x0f];
	volatile unsigned char dma_addr0; 	/* DMA address (MSB) [0x010] */
	unsigned char dmapad2[0x03];
	volatile unsigned char dma_addr1; 	/* DMA address       [0x014] */
	unsigned char dmapad3[0x03];
	volatile unsigned char dma_addr2; 	/* DMA address       [0x018] */
	unsigned char dmapad4[0x03];
	volatile unsigned char dma_addr3; 	/* DMA address (LSB) [0x01c] */
};

/* DMA control bits */
#define BLZ2060_DMA_LED    0x02		/* HD led control 1 = off */

/*
 * m68k always assumes readl/writel operate on little endian
 * mmio space; this is wrong at least for Sun3x, so we
 * need to workaround this until a proper way is found
 */
#if 0
#define dma_read32(REG) \
	readl(esp->dma_regs + (REG))
#define dma_write32(VAL, REG) \
	writel((VAL), esp->dma_regs + (REG))
#else
#define dma_read32(REG) \
	*(volatile u32 *)(esp->dma_regs + (REG))
#define dma_write32(VAL, REG) \
	do { *(volatile u32 *)(esp->dma_regs + (REG)) = (VAL); } while (0)
#endif

/*
 * On all implementations except for the Oktagon, padding between ESP 
 * registers is three bytes.
 * On Oktagon, it is one byte - use a different accessor there. 
 *
 * Oktagon currently unsupported!
 */

static void zorro_esp_write8(struct esp *esp, u8 val, unsigned long reg)
{
	writeb(val, esp->regs + (reg * 4UL));
}

static u8 zorro_esp_read8(struct esp *esp, unsigned long reg)
{
	return readb(esp->regs + (reg * 4UL));
}

static dma_addr_t zorro_esp_map_single(struct esp *esp, void *buf,
				      size_t sz, int dir)
{
	return dma_map_single(esp->dev, buf, sz, dir);
}

static int zorro_esp_map_sg(struct esp *esp, struct scatterlist *sg,
				  int num_sg, int dir)
{
	return dma_map_sg(esp->dev, sg, num_sg, dir);
}

static void zorro_esp_unmap_single(struct esp *esp, dma_addr_t addr,
				  size_t sz, int dir)
{
	dma_unmap_single(esp->dev, addr, sz, dir);
}

static void zorro_esp_unmap_sg(struct esp *esp, struct scatterlist *sg,
			      int num_sg, int dir)
{
	dma_unmap_sg(esp->dev, sg, num_sg, dir);
}

static int zorro_esp_irq_pending(struct esp *esp)
{
	/* check ESP status register; DMA has no status reg. */

	if ( zorro_esp_read8(esp,ESP_STATUS) & ESP_STAT_INTR )
		return 1;

	return 0;
}

static void zorro_esp_reset_dma(struct esp *esp)
{
	/* nothing to do here */
}

static void zorro_esp_dma_drain(struct esp *esp)
{
	/* nothing to do here */
}

static void zorro_esp_dma_invalidate(struct esp *esp)
{
	/* nothing to do here */
}

#ifdef ZORRO_ESP_PIO_CMD
static void zorro_esp_send_pio_cmd(struct esp *esp, u32 esp_count,
					int write, u8 cmd)
{
	/*
	NOTE that this function is only for esp->command_block!
	*/

	u32 i, j;
	u32 fbytes = 0;

	if (esp_count > 16) {
		printk( "zorro_esp: PIO: Too many bytes for command block transfer!\n" );
		return;
	}

	cmd &= ~(ESP_CMD_DMA);

        if (write) {
                scsi_esp_cmd(esp, cmd);

		j = 0;
		while (1) {
			i = 0;
			fbytes = 0;
	                while (!fbytes) {
				fbytes = zorro_esp_read8(esp, ESP_FFLAGS) & ESP_FF_FBYTES;
				i++;
				if ( i > 1000000 ) break;
				udelay(1);
			}

			if (!fbytes) break;

			while (fbytes) {
				esp->command_block[j++] = zorro_esp_read8(esp, ESP_FDATA);
				fbytes--;
			}

			if ( j == esp_count ) break;

			i = 0;
	                while (!zorro_esp_irq_pending(esp)) {
				i++;
				if ( i > 1000000 ) break;
				udelay(1);
			}

			if ( i > 1000000 ) {
				printk( "zorro_esp: PIO: IRQ TIMEOUT!\n" );
				break;
				}

                        scsi_esp_cmd(esp, ESP_CMD_TI);
		}

	} else {
		scsi_esp_cmd(esp, ESP_CMD_FLUSH);
		fbytes = esp_count;
		for (i=0;i<fbytes;i++) zorro_esp_write8(esp, esp->command_block[i], ESP_FDATA);
                scsi_esp_cmd(esp, cmd);
	}

	if ( j != esp_count )
		printk( "zorro_esp: PIO: %d bytes transferred out of %d expected.\n" );

}
#endif /* ZORRO_ESP_PIO_CMD */

// Blizzard 1230/60 SCSI-IV DMA

static void zorro_esp_send_blz1230_dma_cmd(struct esp *esp, u32 addr,
			u32 esp_count, u32 dma_count, int write, u8 cmd)
{
	struct blz1230_dma_registers *dregs = (struct blz1230_dma_registers *) (esp->dma_regs);

#ifdef ZORRO_ESP_PIO_CMD
	if (addr == esp->command_block_dma) {
		zorro_esp_send_pio_cmd(esp, esp_count, write, cmd);
		return;
		}
#endif
	BUG_ON(!(cmd & ESP_CMD_DMA));

	if (write)
		cache_clear(addr, esp_count);
	else
		cache_push(addr, esp_count);

	addr >>= 1;
	if (write)
		addr &= ~(DMA_WRITE);
	else
		addr |= DMA_WRITE;

	dregs->dma_latch = (addr >> 24) & 0xff;
	dregs->dma_addr = (addr >> 24) & 0xff;
	dregs->dma_addr = (addr >> 16) & 0xff;
	dregs->dma_addr = (addr >>  8) & 0xff;
	dregs->dma_addr = (addr      ) & 0xff;

	scsi_esp_cmd(esp, ESP_CMD_DMA);
	zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
	zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
//	zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);

	scsi_esp_cmd(esp, cmd);
}

// Blizzard 2060 DMA

static void zorro_esp_send_blz2060_dma_cmd(struct esp *esp, u32 addr,
			u32 esp_count, u32 dma_count, int write, u8 cmd)
{
	struct blz2060_dma_registers *dregs = (struct blz2060_dma_registers *) (esp->dma_regs);

#ifdef ZORRO_ESP_PIO_CMD
	if (addr == esp->command_block_dma) {
		zorro_esp_send_pio_cmd(esp, esp_count, write, cmd);
		return;
		}
#endif
	BUG_ON(!(cmd & ESP_CMD_DMA));

	if (write)
		cache_clear(addr, esp_count);
	else
		cache_push(addr, esp_count);

	addr >>= 1;
	if (write)
		addr &= ~(DMA_WRITE);
	else
		addr |= DMA_WRITE;

	dregs->dma_addr3 = (addr      ) & 0xff;
	dregs->dma_addr2 = (addr >>  8) & 0xff;
	dregs->dma_addr1 = (addr >> 16) & 0xff;
	dregs->dma_addr0 = (addr >> 24) & 0xff;

	scsi_esp_cmd(esp, ESP_CMD_DMA);
	zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
	zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
//	zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);

	scsi_esp_cmd(esp, cmd);
}

static int zorro_esp_dma_error(struct esp *esp)
{
	/* nothing to do here - there seems to be no way to check for DMA errors */
	return 0;
}

static struct esp_driver_ops zorro_esp_ops = {
	.esp_write8	=	zorro_esp_write8,
	.esp_read8	=	zorro_esp_read8,
	.map_single	=	zorro_esp_map_single,
	.map_sg		=	zorro_esp_map_sg,
	.unmap_single	=	zorro_esp_unmap_single,
	.unmap_sg	=	zorro_esp_unmap_sg,
	.irq_pending	=	zorro_esp_irq_pending,
	.reset_dma	=	zorro_esp_reset_dma,
	.dma_drain	=	zorro_esp_dma_drain,
	.dma_invalidate	=	zorro_esp_dma_invalidate,
	.send_dma_cmd	=	zorro_esp_send_blz2060_dma_cmd,
	.dma_error	=	zorro_esp_dma_error,
};

static int zorro_esp_slave_configure(struct scsi_device *dev)
{
	/*
	 This function is used instead of the original
	 esp_scsi.c: esp_slave_configure() to hardwire
	 TCQ off until someone finds out where things
	 go wrong.
	*/

	struct esp *esp = shost_priv(dev->host);
	struct esp_target_data *tp = &esp->target[dev->id];

	scsi_deactivate_tcq(dev, dev->host->cmd_per_lun);
        tp->flags |= ESP_TGT_DISCONNECT;

        if (!spi_initial_dv(dev->sdev_target))
                spi_dv_device(dev);

        return 0;
}

static int zorro_esp_init_one(struct zorro_dev *z,
				       const struct zorro_device_id *ent)
{
	struct scsi_host_template *tpnt = &scsi_esp_template;
	struct Scsi_Host *host;
	struct esp *esp;
	struct zorro_driver_data *zdd;
	unsigned long board, ioaddr, dmaaddr;
	int err = -ENOMEM;

	board = zorro_resource_start(z);
	zdd = (struct zorro_driver_data *)ent->driver_data;

	printk( "zorro_esp: %s found at address 0x%lx.\n", zdd->name, board );

	if (zdd->absolute) {
		ioaddr  = zdd->offset;
		dmaaddr = zdd->dma_offset;
	} else {
		ioaddr  = board + zdd->offset;
		dmaaddr = board + zdd->dma_offset;
	}

	if (!zorro_request_device(z, zdd->name)) {
		printk(KERN_ERR "zorro_esp: cannot reserve region 0x%lx, abort\n",
		       board);
		return -EBUSY;
	}

	host = scsi_host_alloc(tpnt, sizeof(struct esp));

	if (!host) {
		printk(KERN_ERR "zorro_esp: No host detected; "
				"board configuration problem?\n");
		goto out_free;
	}

	host->base		= ioaddr;
        host->this_id		= 7;

	esp			= shost_priv(host);
	esp->host		= host;
	esp->dev		= &z->dev;

	esp->scsi_id		= host->this_id;
	esp->scsi_id_mask	= (1 << esp->scsi_id);

	/* Switch to the correct the DMA routine and clock frequency. */
	switch ( ent->id ) {
	case ZORRO_PROD_PHASE5_BLIZZARD_2060: {
		zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz2060_dma_cmd;
		esp->cfreq = 40000000;
		break;
		}
	case ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260: {
		zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz1230_dma_cmd;
		esp->cfreq = 40000000;
		break;
		}
	default: {
		/* Oh noes */
		printk(KERN_ERR "zorro_esp: Unsupported board!\n");
		goto fail_free_host;
		break;
		}
	}

	esp->ops = &zorro_esp_ops;

	if (ioaddr > 0xffffff)
		esp->regs = ioremap_nocache(ioaddr, 0x20);
	else
		esp->regs = (void __iomem *)ZTWO_VADDR(ioaddr);

	if (!esp->regs)
		goto fail_free_host;

	/* Let's check whether a Blizzard 12x0 really has SCSI */
	if ((ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260) ||
	   (ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060)) {
		zorro_esp_write8(esp, (ESP_CONFIG1_PENABLE | 7), ESP_CFG1);
		if ( zorro_esp_read8(esp, ESP_CFG1) != (ESP_CONFIG1_PENABLE | 7) )
			goto fail_free_host;
	}

	if (ioaddr > 0xffffff) {
		// I guess the Fastlane Z3 will be the only one to catch this?
		// Here's a placeholder for now...
		if ( ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260 )
			esp->dma_regs = ioremap_nocache( dmaaddr, sizeof(struct blz1230_dma_registers) );
	} else
		esp->dma_regs = (void __iomem *)ZTWO_VADDR(dmaaddr);

	if (!esp->dma_regs)
		goto fail_unmap_regs;

	esp->command_block = dma_alloc_coherent(esp->dev, 16,
						&esp->command_block_dma,
						GFP_KERNEL);

	if (!esp->command_block)
		goto fail_unmap_dma_regs;

	host->irq = IRQ_AMIGA_PORTS;
	err = request_irq(host->irq, scsi_esp_intr, IRQF_SHARED,
			  "Amiga Zorro ESP", esp);
	if (err < 0)
		goto fail_free_command_block;

//	esp->flags = ESP_FLAG_DISABLE_SYNC;

	/* register the chip */
	err = scsi_esp_register(esp, &z->dev);
	if (err)
		goto fail_free_irq;

	esp->config2 = ESP_CONFIG2_SCSI2ENAB;
	zorro_esp_write8(esp, esp->config2, ESP_CFG2);


	zorro_set_drvdata(z, host);

	return 0;

fail_free_irq:
	free_irq(host->irq, esp);

fail_free_command_block:
	dma_free_coherent(esp->dev, 16,
			  esp->command_block,
			  esp->command_block_dma);

fail_unmap_dma_regs:
	if (ioaddr > 0xffffff)
		iounmap(esp->dma_regs);

fail_unmap_regs:
	if (ioaddr > 0xffffff)
		iounmap(esp->regs);

fail_free_host:
	scsi_host_put(host);

out_free:
	zorro_release_device(z);

	return -ENODEV;
}

static void zorro_esp_remove_one(struct zorro_dev *z)
{
	struct Scsi_Host *host = zorro_get_drvdata(z);
	struct esp *esp	= shost_priv(host);

	scsi_esp_unregister(esp);

	/* Disable interrupts. Perhaps use disable_irq instead ... */

	free_irq(host->irq, esp);
	dma_free_coherent(esp->dev, 16,
			  esp->command_block,
			  esp->command_block_dma);

	if ( host->base > 0xffffff ) {
		iounmap(esp->dma_regs);
		iounmap(esp->regs);
		}

	scsi_host_put(host);

	zorro_release_device(z);
}

static struct zorro_driver zorro_esp_driver = {
	.name	  = "zorro_esp-scsi",
	.id_table = zorro_esp_zorro_tbl,
	.probe	  = zorro_esp_init_one,
	.remove	  = zorro_esp_remove_one,
};

static int __init zorro_esp_scsi_init(void)
{
	return zorro_register_driver(&zorro_esp_driver);
}

static void __exit zorro_esp_scsi_exit(void)
{
	zorro_unregister_driver(&zorro_esp_driver);
}

module_init(zorro_esp_scsi_init);
module_exit(zorro_esp_scsi_exit);

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-14  2:14                                               ` David Miller
  2014-04-14  5:05                                                 ` Tuomas Vainikka
@ 2014-04-14  9:01                                                 ` Michael Schmitz
  2014-05-04 11:41                                                   ` Tuomas Vainikka
  2016-10-28 21:54                                                 ` Finn Thain
  2 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2014-04-14  9:01 UTC (permalink / raw)
  To: David Miller; +Cc: linux-m68k, geert, jongk, tuomas.vainikka, linux-scsi

Hi Dave,

>>> When this bit is set, the 53CF94/96 can receive 3-byte messages  
>>> during
>>> bus-initiated Select With ATN. This feature is also enabled by  
>>> setting
>>> bit 3 in the Configuration 2 register.
>>
>> My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
>> opinion, Dave?
>
> As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
> (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
> mode.  So it is not relevant for our discussion because this driver is
> for initiator mode operation only.

Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have  
unintended side effects. It's just easier to test whether this fixes  
our problem.

>
> But some pieces of documentation seem like they might not agree on
> this point.
>
> With respect to bit 3 in the config3 register, it can take on one of
> two meaning depending upon chip revision.  As per  
> ESP_CONFIG3_{TMS,FCLK}
> it either controls fast SCSI clocking, or it enabled 3 byte message
> recognition.
>
> But oddly in the NCR53CX docs:
>
> 	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/ 
> NCR53C9X.txt
>
> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
> which enables both features.

That's what I understood from the bits Kars quoted, yes. And in the  
Amiga driver cases, it will always be the 3 byte message feature  
controlled by that bit, as far as I can see.

>
> Again I looked at the FreeBSD driver and for all chips after plain
> esp100, they set ESP_CONFIG2_SCSI2ENAB.
>
> Can we try testing the following patch?

That would be even easier than setting it explicitly in the Zorro  
driver, thanks,

	Michael


>
> ====================
> esp_scsi: Set SCSI2 bit in config2 register.
>
> This should allow proper recognition of 3 byte reselection
> on all esp100a and later chips.
>
> Reported-by: Kars de Jong <jongk@linux-m68k.org>
> Reported-by: Michael Schmitz <schmitzmic@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 55548dc..16f69e0 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
>  		 */
>  		esp->rev = ESP100;
>  	} else {
> -		esp->config2 = 0;
> +		esp->config2 = ESP_CONFIG2_SCSI2ENAB;
>  		esp_set_all_config3(esp, 5);
>  		esp->prev_cfg3 = 5;
>  		esp_write8(esp->config2, ESP_CFG2);
> @@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
>  			} else {
>  				esp->rev = ESP236;
>  			}
> -			esp->config2 = 0;
> -			esp_write8(esp->config2, ESP_CFG2);
>  		}
>  	}
>  }

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-14  9:01                                                 ` Michael Schmitz
@ 2014-05-04 11:41                                                   ` Tuomas Vainikka
  0 siblings, 0 replies; 23+ messages in thread
From: Tuomas Vainikka @ 2014-05-04 11:41 UTC (permalink / raw)
  To: Michael Schmitz, David Miller; +Cc: linux-m68k, geert, jongk, linux-scsi

[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]

On 14.04.2014 12:01, Michael Schmitz wrote:
> Hi Dave,
>
>>>> When this bit is set, the 53CF94/96 can receive 3-byte messages during
>>>> bus-initiated Select With ATN. This feature is also enabled by setting
>>>> bit 3 in the Configuration 2 register.
>>>
>>> My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
>>> opinion, Dave?
>>
>> As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
>> (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
>> mode.  So it is not relevant for our discussion because this driver is
>> for initiator mode operation only.
>
> Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have 
> unintended side effects. It's just easier to test whether this fixes 
> our problem.
>
>>
>> But some pieces of documentation seem like they might not agree on
>> this point.
>>
>> With respect to bit 3 in the config3 register, it can take on one of
>> two meaning depending upon chip revision.  As per ESP_CONFIG3_{TMS,FCLK}
>> it either controls fast SCSI clocking, or it enabled 3 byte message
>> recognition.
>>
>> But oddly in the NCR53CX docs:
>>
>>     http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt 
>>
>>
>> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
>> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
>> which enables both features.
>
> That's what I understood from the bits Kars quoted, yes. And in the 
> Amiga driver cases, it will always be the 3 byte message feature 
> controlled by that bit, as far as I can see.
>
>>
>> Again I looked at the FreeBSD driver and for all chips after plain
>> esp100, they set ESP_CONFIG2_SCSI2ENAB.
>>
>> Can we try testing the following patch?
>
> That would be even easier than setting it explicitly in the Zorro 
> driver, thanks,
>
>     Michael
>
>
>>
>> ====================
>> esp_scsi: Set SCSI2 bit in config2 register.
>>
>> This should allow proper recognition of 3 byte reselection
>> on all esp100a and later chips.
>>
>> Reported-by: Kars de Jong <jongk@linux-m68k.org>
>> Reported-by: Michael Schmitz <schmitzmic@gmail.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
>> index 55548dc..16f69e0 100644
>> --- a/drivers/scsi/esp_scsi.c
>> +++ b/drivers/scsi/esp_scsi.c
>> @@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
>>           */
>>          esp->rev = ESP100;
>>      } else {
>> -        esp->config2 = 0;
>> +        esp->config2 = ESP_CONFIG2_SCSI2ENAB;
>>          esp_set_all_config3(esp, 5);
>>          esp->prev_cfg3 = 5;
>>          esp_write8(esp->config2, ESP_CFG2);
>> @@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
>>              } else {
>>                  esp->rev = ESP236;
>>              }
>> -            esp->config2 = 0;
>> -            esp_write8(esp->config2, ESP_CFG2);
>>          }
>>      }
>>  }
>
Hello,

The patch above doesn't work. I've attached a log. Looks like the same 
problem we've had all along.
The gzipped logs have all esp_scsi debug messages enabled for a 
non-patched and patched versions.

-Tuomas

[-- Attachment #2: 0005_zorroesp.txt --]
[-- Type: text/plain, Size: 33592 bytes --]

modprobe zorro_esp
zorro_esp: Blizzard 1230 found at address 0xea0000.
esp: esp0, regs[80ea8000:80eb0000] irq[2]
esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
scsi 0:0:2:0: Direct-Access     SEAGATE  ST51080N         0913 PQ: 0 ANSI: 2
scsi target0:0:2: Beginning Domain Validation
scsi target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
scsi target0:0:2: Domain Validation skipping write tests
scsi target0:0:2: Ending Domain Validation
sd 0:0:2:0: [sda] 2109840 512-byte logical blocks: (1.08 GB/1.00 GiB)
sd 0:0:2:0: [sda] Write Protect is off
sd 0:0:2:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:2:0: Attached scsi generic sg0 type 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
Dev sda: unable to read RDB block 0
 sda: unable to read partition table
sd 0:0:2:0: [sda] Attached SCSI disk
root@amiga:~# esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 80 00 00 08 00
end_request: I/O error, dev sda, sector 2109824
Buffer I/O error on device sda, logical block 263728
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 80 00 00 08 00
end_request: I/O error, dev sda, sector 2109824
Buffer I/O error on device sda, logical block 263728
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
end_request: I/O error, dev sda, sector 8
Buffer I/O error on device sda, logical block 1
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
end_request: I/O error, dev sda, sector 2109832
Buffer I/O error on device sda, logical block 263729
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 50 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 80 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 20 31 88 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 08 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
blk_update_request: 24 callbacks suppressed
end_request: I/O error, dev sda, sector 0
quiet_error: 24 callbacks suppressed
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 78 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 78 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 78 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 78 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 78 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 78 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 10 00 00 08 00
blk_update_request: 32 callbacks suppressed
end_request: I/O error, dev sda, sector 16
quiet_error: 32 callbacks suppressed
Buffer I/O error on device sda, logical block 2
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
end_request: I/O error, dev sda, sector 128
Buffer I/O error on device sda, logical block 16
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
end_request: I/O error, dev sda, sector 128
Buffer I/O error on device sda, logical block 16
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
end_request: I/O error, dev sda, sector 128
Buffer I/O error on device sda, logical block 16
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 10 00 00 08 00
end_request: I/O error, dev sda, sector 16
Buffer I/O error on device sda, logical block 2
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
end_request: I/O error, dev sda, sector 128
Buffer I/O error on device sda, logical block 16
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
end_request: I/O error, dev sda, sector 64
Buffer I/O error on device sda, logical block 8
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
end_request: I/O error, dev sda, sector 64
Buffer I/O error on device sda, logical block 8
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
end_request: I/O error, dev sda, sector 64
Buffer I/O error on device sda, logical block 8
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
end_request: I/O error, dev sda, sector 64
Buffer I/O error on device sda, logical block 8
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 40 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 01 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 10 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 10 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 10 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
blk_update_request: 32 callbacks suppressed
end_request: I/O error, dev sda, sector 0
quiet_error: 32 callbacks suppressed
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 08 00 00 08 00
end_request: I/O error, dev sda, sector 8
Buffer I/O error on device sda, logical block 1
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 80 00 00 08 00
end_request: I/O error, dev sda, sector 128
Buffer I/O error on device sda, logical block 16
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 10 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 18 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 38 00 00 08 00
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]  
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB: 
Read(10): 28 00 00 00 00 00 00 00 08 00

root@amiga:~# lsmod
Module                  Size  Used by
sg                     19108  0 
zorro_esp               3338  0 
esp_scsi               21298  1 zorro_esp
nfsd                   67490  0 
ipv6                  229989  24 
evdev                   8390  0 
root@amiga:~# 

[-- Attachment #3: 0009_zorroesp_espscsi_patched.txt.gz --]
[-- Type: application/gzip, Size: 3389 bytes --]

[-- Attachment #4: 0008_zorroesp_espscsi_no_patch.txt.gz --]
[-- Type: application/gzip, Size: 3350 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-14  8:51                                                   ` Michael Schmitz
@ 2014-05-25  8:56                                                     ` Geert Uytterhoeven
  2014-05-26  1:15                                                       ` Michael Schmitz
  0 siblings, 1 reply; 23+ messages in thread
From: Geert Uytterhoeven @ 2014-05-25  8:56 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: Tuomas Vainikka, scsi, Linux/m68k, David Miller, Kars de Jong

Hi Michael,

[sorry for the long delay]

On Mon, Apr 14, 2014 at 10:51 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> Not sure my patch had ever made it into Geert's m68k-queue - except for the
> patch in my previous mail, my zorro_esp.c is still the same as I got from
> you in October last year. The project has been on the back burner for too
> long ...

I don't think it makes much sense to add it to my queue, as it's purely SCSI
and not critical for current m68k.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-05-25  8:56                                                     ` Geert Uytterhoeven
@ 2014-05-26  1:15                                                       ` Michael Schmitz
  0 siblings, 0 replies; 23+ messages in thread
From: Michael Schmitz @ 2014-05-26  1:15 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Tuomas Vainikka, scsi, Linux/m68k, David Miller, Kars de Jong

Hi Geert,

> [sorry for the long delay]

Tell me about it :-) I haven't had a good idea how to address this
problem so rather kept mum about it.

> On Mon, Apr 14, 2014 at 10:51 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Not sure my patch had ever made it into Geert's m68k-queue - except for the
>> patch in my previous mail, my zorro_esp.c is still the same as I got from
>> you in October last year. The project has been on the back burner for too
>> long ...
>
> I don't think it makes much sense to add it to my queue, as it's purely SCSI
> and not critical for current m68k.

Fine, Ill try and resolve that with Dave then. Tuomas will need to do
the testing (unless someone wants to drop off the necessary hardware
with me - unlikely).

Thanks,

  Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2014-04-14  2:14                                               ` David Miller
  2014-04-14  5:05                                                 ` Tuomas Vainikka
  2014-04-14  9:01                                                 ` Michael Schmitz
@ 2016-10-28 21:54                                                 ` Finn Thain
  2016-10-30  2:33                                                   ` Finn Thain
  2 siblings, 1 reply; 23+ messages in thread
From: Finn Thain @ 2016-10-28 21:54 UTC (permalink / raw)
  To: David Miller
  Cc: schmitzmic, jongk, tuomas.vainikka, geert, linux-m68k, linux-scsi


On Sun, 13 Apr 2014, David Miller wrote:

> > esp_get_revision but later cleared in the same function. It appears 
> > we'd need to set it after the call to scsi_esp_register() - can you 
> > test whether that obsoletes the zorro_esp_slave_configure hack, 
> > Tuomas?
>  ...
> > > Group 2 Commands
> > > (seems to only be relevant for target mode).
> > >
> > > And about the QTE bit:
> > >
> > > Bit 6 Queue Tag Enable
> > >
> > > When this bit is set, the 53CF94/96 can receive 3-byte messages 
> > > during bus-initiated Select With ATN. This feature is also enabled 
> > > by setting bit 3 in the Configuration 2 register.
> > 
> > My preference would be to set this one (named ESP_CONFIG3_TBMS). Your 
> > opinion, Dave?
> 
> As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register 
> (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target 
> mode.  So it is not relevant for our discussion because this driver is 
> for initiator mode operation only.
> 
> But some pieces of documentation seem like they might not agree on this 
> point.

I think there is ambiguity, and I see some differences between the 
documentation for ESP236 and that for FAS236 devices. But I don't agree 
that ESP_CONFIG2_SCSI2ENAB is only for target mode.

This bug affects re-selection. So documentation which refers to a "device 
[being] selected" tends to be ambiguous, because re-selection is still 
selection in some sense. E.g. the Am53C94/Am53C96 (preliminary) datasheet 
says this:

    Extended Message Feature: When the S2FE [ESP_CONFIG2_SCSI2ENAB] bit is 
    set and the device is selected with attention, the device will monitor 
    the /ATN signal at the end of the first message byte. If the /ATN 
    signal is active, the device will request two more message bytes 
    before switching to the command phase. If the /ATN signal is inactive 
    the device will switch to the command phase.

But the next part is clear enough and seems to explain the mac_esp 
(ESP236) failure:

    When the S2FE bit is reset the device as a target will request a 
    single message byte. As an initiator, the device will abort the 
    selection sequence if the target does not switch to the command phase 
    after receiving a single message byte.

The document you cited, NCR53C9X.txt, seems unambiguous about the role of 
the initiator. (Just search for "identify message" to see the relevant 
parts.)

Moreover, for reselection, NCR53C9X.txt says the chip will expect 2 tag 
bytes only when tagged queueing is enabled, that is, QTE bit aka 
ESP_CONFIG3_TMS bit is set. The QTE feature "is also enabled by setting 
bit 3 in the Configuration 2 register", aka ESP_CONFIG2_SCSI2ENAB, which 
is what your patch does.

> 
> With respect to bit 3 in the config3 register, it can take on one of
> two meaning depending upon chip revision.  As per ESP_CONFIG3_{TMS,FCLK}
> it either controls fast SCSI clocking, or it enabled 3 byte message
> recognition.
> 
> But oddly in the NCR53CX docs:
> 
> 	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
> 
> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
> which enables both features.

Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only problem 
is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, when the 
CONFIG3 register is written to?

> 
> Again I looked at the FreeBSD driver and for all chips after plain 
> esp100, they set ESP_CONFIG2_SCSI2ENAB.
> 
> Can we try testing the following patch?

It could be that this patch would be sufficient to fix mac_esp because 
ESP236 seems to have no ESP_CONFIG3_TMS bit.

We know that this patch didn't work for zorro_esp (FAS236) but it would be 
helpful to know what value the CONFIG3 register took in the end.

-- 

> 
> ====================
> esp_scsi: Set SCSI2 bit in config2 register.
> 
> This should allow proper recognition of 3 byte reselection
> on all esp100a and later chips.
> 
> Reported-by: Kars de Jong <jongk@linux-m68k.org>
> Reported-by: Michael Schmitz <schmitzmic@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 55548dc..16f69e0 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
>  		 */
>  		esp->rev = ESP100;
>  	} else {
> -		esp->config2 = 0;
> +		esp->config2 = ESP_CONFIG2_SCSI2ENAB;
>  		esp_set_all_config3(esp, 5);
>  		esp->prev_cfg3 = 5;
>  		esp_write8(esp->config2, ESP_CFG2);
> @@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
>  			} else {
>  				esp->rev = ESP236;
>  			}
> -			esp->config2 = 0;
> -			esp_write8(esp->config2, ESP_CFG2);
>  		}
>  	}
>  }

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2016-10-28 21:54                                                 ` Finn Thain
@ 2016-10-30  2:33                                                   ` Finn Thain
  2016-10-31  8:03                                                     ` Michael Schmitz
  0 siblings, 1 reply; 23+ messages in thread
From: Finn Thain @ 2016-10-30  2:33 UTC (permalink / raw)
  To: David Miller
  Cc: schmitzmic, jongk, tuomas.vainikka, geert, linux-m68k, linux-scsi


On Sat, 29 Oct 2016, I wrote:

> 
> On Sun, 13 Apr 2014, David Miller wrote:
> 
> > 
> > But oddly in the NCR53CX docs:
> > 
> > 	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
> > 
> > it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer 
> > grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB, 
> > which enables both features.
> 
> Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only 
> problem is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, 
> when the CONFIG3 register is written to?
> 

Nevermind my question. To falsify my own theory, I see that 
ESP_CONFIG3_TMS == ESP_CONFIG3_FCLK, and thus esp_scsi does actually set 
the relevant bit, and therefore "the FSC can receive 3-byte messages 
during businitiated select with ATN."

-- 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2016-10-30  2:33                                                   ` Finn Thain
@ 2016-10-31  8:03                                                     ` Michael Schmitz
  2016-10-31 18:54                                                       ` Michael Schmitz
  0 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2016-10-31  8:03 UTC (permalink / raw)
  To: Finn Thain, David Miller
  Cc: jongk, tuomas.vainikka, geert, linux-m68k, linux-scsi

Hi Finn,

Am 30.10.2016 um 15:33 schrieb Finn Thain:
> 
> On Sat, 29 Oct 2016, I wrote:
> 
>>
>> On Sun, 13 Apr 2014, David Miller wrote:
>>
>>>
>>> But oddly in the NCR53CX docs:
>>>
>>> 	http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
>>>
>>> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer 
>>> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB, 
>>> which enables both features.
>>
>> Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only 
>> problem is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, 
>> when the CONFIG3 register is written to?
>>
> 
> Nevermind my question. To falsify my own theory, I see that 
> ESP_CONFIG3_TMS == ESP_CONFIG3_FCLK, and thus esp_scsi does actually set 
> the relevant bit, and therefore "the FSC can receive 3-byte messages 
> during businitiated select with ATN."

>From my reading of the quoted docs,ESP_CONFIG3_TMS is valid for FAS100A
(and later?). What esp_scsi sets (for FAS236 chips) is fast SCSI clock
mode. The relevant bit for three byte message support for Mac and Amiga
ESP hardware should be ESP_CONFIG3_TENB.

I had tried to set that bit in zorro_esp_slave_configure but had not
done a proper job of it - I'd only set esp->config3 and forgot to set
tp->esp_config3. Time to retest this ...

Cheers,

	Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2016-10-31  8:03                                                     ` Michael Schmitz
@ 2016-10-31 18:54                                                       ` Michael Schmitz
  2016-10-31 23:47                                                         ` Finn Thain
  0 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2016-10-31 18:54 UTC (permalink / raw)
  To: Finn Thain, David Miller
  Cc: Kars de Jong, Tuomas Vainikka, Geert Uytterhoeven, Linux/m68k,
	scsi, John Paul Adrian Glaubitz

Hi Finn,

> I had tried to set that bit in zorro_esp_slave_configure but had not
> done a proper job of it - I'd only set esp->config3 and forgot to set
> tp->esp_config3. Time to retest this ...

I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to
be set for all targets if at least one SCSI-2 target is on the bus and
we allow dosconnecting, no?

Adrian - any chance I can get access to elgar again for some more testing?

Cheers,

  Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2016-10-31 18:54                                                       ` Michael Schmitz
@ 2016-10-31 23:47                                                         ` Finn Thain
  2016-11-01  7:09                                                           ` Michael Schmitz
  0 siblings, 1 reply; 23+ messages in thread
From: Finn Thain @ 2016-10-31 23:47 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: David Miller, Kars de Jong, Tuomas Vainikka, Geert Uytterhoeven,
	Linux/m68k, scsi, John Paul Adrian Glaubitz


On Tue, 1 Nov 2016, Michael Schmitz wrote:

> > I had tried to set that bit in zorro_esp_slave_configure but had not 
> > done a proper job of it - I'd only set esp->config3 and forgot to set 
> > tp->esp_config3. Time to retest this ...
> 
> I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to 
> be set for all targets if at least one SCSI-2 target is on the bus and 
> we allow dosconnecting, no?

I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on 
ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit.

The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's 
patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS == 
ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash.

-- 

> 
> Adrian - any chance I can get access to elgar again for some more testing?
> 
> Cheers,
> 
>   Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2016-10-31 23:47                                                         ` Finn Thain
@ 2016-11-01  7:09                                                           ` Michael Schmitz
  2016-11-01  7:23                                                             ` Finn Thain
  0 siblings, 1 reply; 23+ messages in thread
From: Michael Schmitz @ 2016-11-01  7:09 UTC (permalink / raw)
  To: Finn Thain
  Cc: David Miller, Kars de Jong, Tuomas Vainikka, Geert Uytterhoeven,
	Linux/m68k, scsi, John Paul Adrian Glaubitz

Hi Finn,

Am 01.11.2016 um 12:47 schrieb Finn Thain:
> 
> On Tue, 1 Nov 2016, Michael Schmitz wrote:
> 
>>> I had tried to set that bit in zorro_esp_slave_configure but had not 
>>> done a proper job of it - I'd only set esp->config3 and forgot to set 
>>> tp->esp_config3. Time to retest this ...
>>
>> I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to 
>> be set for all targets if at least one SCSI-2 target is on the bus and 
>> we allow dosconnecting, no?
> 
> I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on 
> ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit.

I stand corrected. Err... confused.

When setting ESP_CONFIG3_TBMS, should we set ESP_CONFIG3_GTM as well?

> The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's 
> patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS == 
> ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash.

I'd want to set these bits for ESP236 and FAS236 only, so no clash with
HME. As you found out, ESP_CONFIG3_TBMS aka ESP_CONFIG3_EWIDE gets
clobbered on bus reset cleanup unconditionally.

Cheers,

	Michael

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: esp_scsi QTAG in FAS216
  2016-11-01  7:09                                                           ` Michael Schmitz
@ 2016-11-01  7:23                                                             ` Finn Thain
  0 siblings, 0 replies; 23+ messages in thread
From: Finn Thain @ 2016-11-01  7:23 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: David Miller, Kars de Jong, Tuomas Vainikka, Geert Uytterhoeven,
	Linux/m68k, scsi, John Paul Adrian Glaubitz


On Tue, 1 Nov 2016, Michael Schmitz wrote:

> Hi Finn,
> 
> Am 01.11.2016 um 12:47 schrieb Finn Thain:
> > 
> > On Tue, 1 Nov 2016, Michael Schmitz wrote:
> > 
> >>> I had tried to set that bit in zorro_esp_slave_configure but had not 
> >>> done a proper job of it - I'd only set esp->config3 and forgot to 
> >>> set tp->esp_config3. Time to retest this ...
> >>
> >> I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs 
> >> to be set for all targets if at least one SCSI-2 target is on the bus 
> >> and we allow dosconnecting, no?
> > 
> > I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on 
> > ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit.
> 
> I stand corrected. Err... confused.
> 
> When setting ESP_CONFIG3_TBMS, should we set ESP_CONFIG3_GTM as well?

I think that depends entirely on the target. But it isn't relevant to the 
bug at hand AFAICS.

-- 

> 
> > The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's 
> > patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS 
> > == ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this 
> > clash.
> 
> I'd want to set these bits for ESP236 and FAS236 only, so no clash with 
> HME. As you found out, ESP_CONFIG3_TBMS aka ESP_CONFIG3_EWIDE gets 
> clobbered on bus reset cleanup unconditionally.
> 
> Cheers,
> 
> 	Michael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2016-11-01  7:23 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1370552199-15048-1-git-send-email-schmitz@debian.org>
     [not found] ` <520D4AE3.6040801@aalto.fi>
     [not found]   ` <520E76FC.9040803@aalto.fi>
     [not found]     ` <11425cb5ec432e2fbb7b675052e8b33d@gmail.com>
     [not found]       ` <520F5F81.7090409@aalto.fi>
     [not found]         ` <52102BEC.7000006@gmail.com>
     [not found]           ` <CAMuHMdV9vP-Qg2my5fyT+pa_WcDfZAPx5T1-4kXP8eD1oL8Kog@mail.gmail.com>
     [not found]             ` <52108CAF.1010700@gmail.com>
     [not found]               ` <CAMuHMdWqNBjHKiDojPdjzuOV65QXzjeMX5VbtUvgU7VTP4iYFg@mail.gmail.com>
     [not found]                 ` <5211DBD8.5090801@gmail.com>
     [not found]                   ` <5212840A.4080300@aalto.fi>
     [not found]                     ` <1ef2d87e4efecb2d8c8c2eaf8ac5fd51@gmail.com>
     [not found]                       ` <52133E48.50501@aalto.fi>
     [not found]                         ` <CAOmrzkKtB4OpnFNFh9PR4V8bc3ExfFXpwtkhGj0veQ4w-d=cqA@mail.gmail.com>
     [not found]                           ` <522F8B67.2080603@aalto.fi>
     [not found]                             ` <CAOmrzkKP4YcvnHcrtucMvS9WSaeg+6-qnobOWN6hBK=wkUHemg@mail.gmail.com>
     [not found]                               ` <CAMuHMdUH=9sv-Vb3ZTAGyfvEQOO0x0x1cUYhfd7040k8d+bSYg@mail.gmail.com>
2013-09-12 15:36                                 ` esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver) Tuomas Vainikka
2013-09-26 13:50                                   ` Michael Schmitz
2014-04-04 20:28                                   ` esp_scsi QTAG in FAS216 David Miller
2014-04-06 20:33                                     ` Michael Schmitz
2014-04-07  3:39                                       ` David Miller
2014-04-10 14:31                                       ` Kars de Jong
2014-04-11  1:47                                         ` Michael Schmitz
2014-04-13 14:47                                           ` Kars de Jong
2014-04-13 22:38                                             ` Michael Schmitz
2014-04-14  2:14                                               ` David Miller
2014-04-14  5:05                                                 ` Tuomas Vainikka
2014-04-14  8:51                                                   ` Michael Schmitz
2014-05-25  8:56                                                     ` Geert Uytterhoeven
2014-05-26  1:15                                                       ` Michael Schmitz
2014-04-14  9:01                                                 ` Michael Schmitz
2014-05-04 11:41                                                   ` Tuomas Vainikka
2016-10-28 21:54                                                 ` Finn Thain
2016-10-30  2:33                                                   ` Finn Thain
2016-10-31  8:03                                                     ` Michael Schmitz
2016-10-31 18:54                                                       ` Michael Schmitz
2016-10-31 23:47                                                         ` Finn Thain
2016-11-01  7:09                                                           ` Michael Schmitz
2016-11-01  7:23                                                             ` Finn Thain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).