Modified Linux 4.1.20 (mac+scsi) on Quadra 660av

[Mac User]

Hello,

I'm not able to get the modified Linux 4.1.20 kernel (the one with the
SCSI patches) working on a Quadra 660av. The kernel compiles (in about
18 hours, compared to over 2 weeks on a Mac IIfx), but it panics at boot
with ESP SCSI errors (timeouts, resets, no mode sense). Debian 3.1
(with a Linux 2.2.25 kernel) works on the Quadra 660av. I tried
terminating the external SCSI connection; that did not help. My
internal SCSI disk is a Seagate ST318417N with termination, terminator
power, and terminator power to bus jumpers set.

I can send pictures of the boot screen, or whatever other output might
be helpful. Or if another kernel is in the works, I can wait and try that.

Thanks for any help..

-Stan

[Finn Thain]

On Mon, 1 Aug 2016, Mac User wrote:

> Hello,
>
> I'm not able to get the modified Linux 4.1.20 kernel (the one with the
> SCSI patches) working on a Quadra 660av. The kernel compiles (in about
> 18 hours, compared to over 2 weeks on a Mac IIfx), but it panics at boot
> with ESP SCSI errors (timeouts, resets, no mode sense). Debian 3.1
> (with a Linux 2.2.25 kernel) works on the Quadra 660av. I tried
> terminating the external SCSI connection; that did not help.

Those patches affect only the mac_scsi driver. That means that they have
no effect on Quadras (the hardware requires the mac_esp driver).

The two AV models (Quadra 660av and 840av) are the only machines that
access the ESP chip using PIO. (All of the other Quadras use PDMA.)

What this means is that SCSI transfers on these AV models suffer from
exactly the same limitation as SCSI transfers on the IIfx: the driver does
not make use of the DMA hardware. Hence, Mac OS get about ten times better
disk throughput than Linux on these machines.

Anyway, I have not tested any AV quadra since Linux v3.x. At that time,
mac_esp worked fine on my 660av.

So I suggest trying an older kernel binary. I can build one for you if you
like.

BTW, if you were using a cross-compiler (to build a kernel in minutes
rather than days) you could then use "git bisect" to identify the commit
that caused the regression, if that's what this is.

> My internal SCSI disk is a Seagate ST318417N with termination,
> terminator power, and terminator power to bus jumpers set.

ISTR that no SCSI devices should provide terminator power to the bus
because the Mac does that (except PowerBooks, which do not power the bus).

>
> I can send pictures of the boot screen, or whatever other output might
> be helpful. Or if another kernel is in the works, I can wait and try
> that.

Please send pictures. You can use the kernel parameter
"fbcon=font:ProFont6x11" to get more text on the screen if it scrolls too
fast.

--

[Finn Thain]

On Mon, 1 Aug 2016, Mac User wrote:

> Hello,
>
> I'm not able to get the modified Linux 4.1.20 kernel (the one with the
> SCSI patches) working on a Quadra 660av. The kernel compiles (in about
> 18 hours, compared to over 2 weeks on a Mac IIfx), but it panics at boot
> with ESP SCSI errors (timeouts, resets, no mode sense).

Do you get the same result from the 4.1.23 download?
https://sourceforge.net/projects/linux-mac68k/files/

> Debian 3.1 (with a Linux 2.2.25 kernel) works on the Quadra 660av. I
> tried terminating the external SCSI connection; that did not help.

You should not need an external terminator unless you have external SCSI
devices. If you have disable all of the internal termination, adding an
external terminator could make it work again.

It sounds like you have both an internal CDROM and internal disk drive.
The drive at the end of the bus needs to have its termination enabled.

--

[Finn Thain]

On Tue, 2 Aug 2016, Mac User wrote:

> > Please send pictures. You can use the kernel parameter
> > "fbcon=font:ProFont6x11" to get more text on the screen if it scrolls
> > too fast.
> >
>

> Please see attached. Thanks..
> [...]
> scsi host0: esp
> scsi 0:0:0:0: Direct-Access SEAGATE ST318417N 0105 PQ: 0 ANSI: 3
> scsi target0:0:0: Beginning Domain Validation
> scsi host0: Reconnect IRQ2 timeout

A bit of Googling tells me that I've been here before (I had forgotten):

commit 02507a80b35edd720480540d917e9f92cc371009
Author: Finn Thain <fth...@telegraphics.com.au>
Date: Sat Dec 5 12:30:42 2009 +1100

[SCSI] mac_esp: fix PIO mode, take 2

The mac_esp PIO algorithm no longer works in 2.6.31 and crashes my Centris
660av. So here's a better one.

Also, force async with esp_set_offset() rather than esp_slave_configure().

One of the SCSI drives I tested still doesn't like the PIO mode and fails
with "esp: esp0: Reconnect IRQ2 timeout" (the same drive works fine in
PDMA mode).

This failure happens when esp_reconnect_with_tag() tries to read in two
tag bytes but the chip only provides one (0x20). I don't know what causes
this. I decided not to waste any more time trying to fix it because the
best solution is to rip out the PIO mode altogether and use the DMA
engine.


So it appears that this bug is not a regression. I guess you have 3
options: find a compatible drive, implement DMA with the PSC chip, or
debug the esp_reconnect_with_tag() implementation for PIO use.

Apple never provided public documentation for the PSC chip, which is why
there's no DMA support for SCSI on AV Quadras, and also why we have code
like this in macmace.c:

/* Not sure what this does */

while ((baka = psc_read_long(PSC_MYSTERY)) != psc_read_long(PSC_MYSTERY));
if (!(baka & 0x60000000)) return IRQ_NONE;

You could tackle the esp_reconnect_with_tag() bug by increasing the
ESP_RESELECT_TAG_LIMIT timeout and setting some kernel parameters:
scsi_mod.scan=sync esp_scsi.esp_debug=0x241

In my experience, the only practical way to debug mac scsi drivers is to
make the driver modular, boot over ethernet and then use insmod and rmmod
to test changes to the module.

--

[Mac User]

On 8/2/16 10:16 PM, Finn Thain wrote:
> ...

Thanks for checking, Finn.

As a non-developer, but one who is willing to become more involved, I
have some newbie questions...

Would it make more sense to adapt the last working version of the ESP
SCSI code (apparently from kernel 2.6.30) or try to fix what is there
now (with the goal of having it work with Linux 4.x kernels)? Is anyone
working on this already?

This also affects the Centris 650, perhaps all of the Quadra machines?

Is there a final Debian-approved version of a working ESP SCSI module
(from Linux 2.6.30 or later) that can be used as a starting point?

You said Apple didn't document their PSC chip very well; is there any
documentation at all that Debian can share?

thanks

-Stan

[Finn Thain]

On Wed, 3 Aug 2016, Mac User wrote:

>
> Would it make more sense to adapt the last working version of the ESP
> SCSI code (apparently from kernel 2.6.30) or try to fix what is there
> now (with the goal of having it work with Linux 4.x kernels)?

If you want other people to benefit from your work, and if you want to get
the benefit of other people's work, then you'll want to collaborate with
the upstream project.

That means working with kernel.org, and adhering to the development
practices and standards required of contributions to that project.

>
> Is anyone working on this already?

Not AFAIK. The AV Quadras aren't very common, and this is likely to be a
difficult bug to fix. If you don't already know your way around the kernel
code base, the 53C96 (ESP236) hardware, and/or the SCSI standards, then
the learning curve is probably not going to be rewarded.

>
> This also affects the Centris 650, perhaps all of the Quadra machines?

Did you test any of those machines? Last I heard, the mac_esp driver
worked fine on non-AV Quadras.

>
> Is there a final Debian-approved version of a working ESP SCSI module
> (from Linux 2.6.30 or later) that can be used as a starting point?

I'm not a Debian Developer, but the only "Debian-approved" code that I
know of is the code that Debian ships. As a rule, Debian does not ship
kernel patches that have not first been accepted by kernel.org. (This is
just the nature of collaboration between open source developers, as
opposed to "forking".)

>
> You said Apple didn't document their PSC chip very well; is there any
> documentation at all that Debian can share?

The Peripheral System Controller (PSC) is a proprietary ASIC. It is surely
well documented, but Apple does not share that kind of information with
with customers, users or the open source community. (Aside: I'm guessing
that this is also the reason why AOSP and cyanogenmod are not available
for ipads and iphones.)

--

>
> thanks
>
> -Stan
>
>

[Mac User]

On 8/3/16 10:05 PM, Finn Thain wrote:
>
> On Wed, 3 Aug 2016, Mac User wrote:

> ...

>>
>> This also affects the Centris 650, perhaps all of the Quadra machines?
>
> Did you test any of those machines? Last I heard, the mac_esp driver
> worked fine on non-AV Quadras.

The 4.1.20 kernel failed on my Centris 650 (with a Seagate ST318416N
disk). But I just tested vmlinux-4.1.23-mac_scsi+, and it works. I
haven't tested other Quadras.

>>
>> Is there a final Debian-approved version of a working ESP SCSI module
>> (from Linux 2.6.30 or later) that can be used as a starting point?
>
> I'm not a Debian Developer, but the only "Debian-approved" code that I
> know of is the code that Debian ships. As a rule, Debian does not ship
> kernel patches that have not first been accepted by kernel.org. (This is
> just the nature of collaboration between open source developers, as
> opposed to "forking".)

ok, thanks

-Stan

[Michael Schmitz]

Hi Finn,

the problem with trying to read two tag bytes does sound familiar - I
believe we ran into that one (or a similar one) while trying to revive
the Amiga ESP drivers.

Tuomas used scsi_deactivate_tcq() in a driver specific
esp_slave_configure() hook but that interface later disappeared. In the
last version I tested, I added the following code after domain
validation in the driver specific esp_slave_configure()

+ /*
+ * Hardwire TQC capability of target _off_ after
+ * domain validation (which might have probed and
+ * negotiated TQC available)
+ */
+ dev->tagged_supported = 0;
+ dev->simple_tags = 0;
+

I tried all sorts of things with the chip config registers, to no avail.
Your report that this only happens with some disks exonerates the driver ...

HTH,

Michael

[Finn Thain]

Fri, 28 Oct 2016 14:48:47 +1100 (AEDT)

> Hi Finn,
>
> the problem with trying to read two tag bytes does sound familiar - I
> believe we ran into that one (or a similar one) while trying to revive
> the Amiga ESP drivers.
>

That's intriguing. I hadn't realised that those zorro_esp discussions on
the mailing lists (linked below) covered the same bug I saw in mac_esp in
2009.

http://linux-m68k.vger.kernel.narkive.com/pMVlraRz/patch-0-2-experimental-amiga-zorro-esp-driver
http://markmail.org/message/whgfl2d5jhk3y75t
http://markmail.org/message/qxrwcdpc625mczml

> Tuomas used scsi_deactivate_tcq() in a driver specific
> esp_slave_configure() hook but that interface later disappeared. In the
> last version I tested, I added the following code after domain
> validation in the driver specific esp_slave_configure()
>
> + /*
> + * Hardwire TQC capability of target _off_ after
> + * domain validation (which might have probed and
> + * negotiated TQC available)
> + */
> + dev->tagged_supported = 0;
> + dev->simple_tags = 0;
> +
>
> I tried all sorts of things with the chip config registers, to no avail.

Nonetheless this issue should probably be addressed in the core esp_scsi
driver to avoid duplicating fixes in the board-specific code.

If we can fix this issue in esp_scsi.c, it would be a good idea to get
some reviews for a complete series of patches for the new zorro_esp.c as
well as changes to esp_scsi.c and probably mac_esp.c too.

> Your report that this only happens with some disks exonerates the driver

The fact that zorro_esp is also affected gives me confidence in mac_esp.

Maybe this is an erratum relating to the particular device found in the
Quadra 660av, and has nothing to do with PIO/DMA/PDMA.

Stan, can you check the markings on the SCSI chip in your 660av? It's most
probably the largest device near the two SCSI connectors, possibly
Am53C94?

I wonder why this problem didn't affect the old ESP driver? (Stan pointed
out earlier in this thread that "Debian 3.1 (with a Linux 2.2.25 kernel)
works on the Quadra 660av".)

--

>
> HTH,
>
> Michael
>
>

[Michael Schmitz]

Hi Finn,

>>
>> the problem with trying to read two tag bytes does sound familiar - I
>> believe we ran into that one (or a similar one) while trying to revive
>> the Amiga ESP drivers.
>>
>
> That's intriguing. I hadn't realised that those zorro_esp discussions on
> the mailing lists (linked below) covered the same bug I saw in mac_esp in
> 2009.
>
> http://linux-m68k.vger.kernel.narkive.com/pMVlraRz/patch-0-2-experimental-amiga-zorro-esp-driver
> http://markmail.org/message/whgfl2d5jhk3y75t
> http://markmail.org/message/qxrwcdpc625mczml

I hadn't realized either that you had seen this bug before - I did't
follow Mac issues at all at that time.

>> Tuomas used scsi_deactivate_tcq() in a driver specific
>> esp_slave_configure() hook but that interface later disappeared. In the
>> last version I tested, I added the following code after domain
>> validation in the driver specific esp_slave_configure()
>>
>> + /*
>> + * Hardwire TQC capability of target _off_ after
>> + * domain validation (which might have probed and
>> + * negotiated TQC available)
>> + */
>> + dev->tagged_supported = 0;
>> + dev->simple_tags = 0;
>> +
>>
>> I tried all sorts of things with the chip config registers, to no avail.
>
> Nonetheless this issue should probably be addressed in the core esp_scsi
> driver to avoid duplicating fixes in the board-specific code.

I agree, and that was David Miller's opinion also. But I've never got
any traction with attempts to explicitly enable extended messages (IIRC)
in the driver via ESP config registers. Ran out of ideas and remotely
debugging the module (with the Amiga sitting in Adrian's lab at that
time) was a bit cumbersome.

>
> If we can fix this issue in esp_scsi.c, it would be a good idea to get
> some reviews for a complete series of patches for the new zorro_esp.c as
> well as changes to esp_scsi.c and probably mac_esp.c too.
>
>> Your report that this only happens with some disks exonerates the driver
>
> The fact that zorro_esp is also affected gives me confidence in mac_esp.

True - but what makes the driver work with most disks but fail with
some? Different SCSI command set supported by the disks?

>
> Maybe this is an erratum relating to the particular device found in the
> Quadra 660av, and has nothing to do with PIO/DMA/PDMA.
>
> Stan, can you check the markings on the SCSI chip in your 660av? It's most
> probably the largest device near the two SCSI connectors, possibly
> Am53C94?

Similar - can Zorro ESP users (probably Adrian only at this stage; not
sure whether I'd ever sent a kernel or patches to Christian) check what
ESP chip version and revision level these cards use?

> I wonder why this problem didn't affect the old ESP driver? (Stan pointed
> out earlier in this thread that "Debian 3.1 (with a Linux 2.2.25 kernel)
> works on the Quadra 660av".)

Yep, I wonder about the same thing. Changes to SCSI domain validation,
perhaps even not at the driver but mid level?

I vaguely recall that the old Mac ESP driver explicitly disabled
features like sync negotiation and perhaps others, and the interface to
do that had changed or disappeared after the 2.6 series? (No idea really
when that happened - my last interaction with the ESP driver would have
been almost 18 years ago. Totally different code.)

IIRC the current ESP driver sets the config3 register according to
target capabilities. Can we log that register setting (once, after
initial DV) to see whether it differs between working and non-working
targets?

Cheers,

Michael

[Finn Thain]

On Sun, 30 Oct 2016, Michael Schmitz wrote:

> but what makes the driver work with most disks but fail with some?
> Different SCSI command set supported by the disks?

Anything that would inhibit disconnection/reselection should avoid the
bug. (BTW ISTR that my SCSI2SD never disconnects a command.)

I think the target has to signal SEL-with-ATN during reselection in order
to trigger the bug. I think this is not part of SCSI-1.

The SEL-with-ATN process is discussed in the "Configuration Register 3"
section, Bit 3, in
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt

> > I wonder why this problem didn't affect the old ESP driver? (Stan
> > pointed out earlier in this thread that "Debian 3.1 (with a Linux
> > 2.2.25 kernel) works on the Quadra 660av".)
>
> Yep, I wonder about the same thing. Changes to SCSI domain validation,
> perhaps even not at the driver but mid level?

Quite possible. I recall you said that you were able to resolve the issue
with a patch to domain validation in the SCSI ML which would inhibit
tagged queueing.

But we really need David's patch, otherwise we probably end up with domain
validation reporting a SCSI-2 device with the ESP left in SCSI-1 mode.

>
> I vaguely recall that the old Mac ESP driver explicitly disabled
> features like sync negotiation and perhaps others, and the interface to
> do that had changed or disappeared after the 2.6 series? (No idea really
> when that happened - my last interaction with the ESP driver would have
> been almost 18 years ago. Totally different code.)

The present mac_esp also disables sync transfers for PIO mode because I
found that necessary. (Async PIO might be impossible.)

printk(KERN_INFO PFX "using PIO for controller %d\n", dev->id);
esp_write8(0, ESP_TCLOW);
esp_write8(0, ESP_TCMED);
esp->flags = ESP_FLAG_DISABLE_SYNC;
mac_esp_ops.send_dma_cmd = mac_esp_send_pio_cmd;

Tuomas reported that PIO instead of DMA did not affect the bug. But my
recall is that the disk which would not work on my Quadra 660av (which
uses PIO exclusively) did in fact work on a different kind of Quadra
(which used PDMA, but also probably has different ESP silicon).

Anyway, is safe to do this?

esp->ops->send_dma_cmd(esp, esp->command_block_dma,
2, 2, 1, ESP_CMD_DMA | ESP_CMD_TI);

/* ACK the message. */
scsi_esp_cmd(esp, ESP_CMD_MOK);

For PIO and PDMA, the transfer will be finished before the MOK ("Message
Accepted") command, but for DMA this seems to be racey...

--

[Geert Uytterhoeven]

On Mon, Oct 31, 2016 at 8:40 AM, Michael Schmitz <schmi...@gmail.com> wrote:
> What chip revision is this doc for? As far as I can make out, it should
> be fas100a? The esp_scsi.h comments suggest the tagged queuing bit is
> for revisions > fas236. The chips used on Macs were probably esp236 or
> fas236? Depending on the

... ?

BTW, shouldn't this conversation be CCed to linux-scsi?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

[Michael Schmitz]

Hi Finn,

Am 30.10.2016 um 18:52 schrieb Finn Thain:
>
> On Sun, 30 Oct 2016, Michael Schmitz wrote:
>
>> but what makes the driver work with most disks but fail with some?
>> Different SCSI command set supported by the disks?
>
> Anything that would inhibit disconnection/reselection should avoid the
> bug. (BTW ISTR that my SCSI2SD never disconnects a command.)
>
> I think the target has to signal SEL-with-ATN during reselection in order
> to trigger the bug. I think this is not part of SCSI-1.
>
> The SEL-with-ATN process is discussed in the "Configuration Register 3"
> section, Bit 3, in
> http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt

What chip revision is this doc for? As far as I can make out, it should
be fas100a? The esp_scsi.h comments suggest the tagged queuing bit is
for revisions > fas236. The chips used on Macs were probably esp236 or
fas236? Depending on the

Not sure whether select with attention is present in SCSI-1, but tagged
queueing (which requires extended messages) is a SCSI-2 feature. So we
will need bit 3 in config2 set if any target support SCSI-2. From my
reading of esp_get_rev(), it's not currently set there (cleared when
config2 readback test is prepared and not restored after it's clear we
have better than ESP100). I suggest config2 is set to
ESP_CONFIG2_SCSI2ENAB before the config3 readback test is done.

Now what I'm unclear on is the interaction between the config2 setting
and the value of bit 3 in config3:

> Bit 3 Queue Tag Enable
>
> When this bit is set, the FSC can receive 3-byte messages
> during businitiated select with ATN. This feature is also enabled by
> setting bit 3 in the Configuration 2 register. The message bytes
> consist of a 1-byte Identify message and a 2-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
> cheked to see if it is a valid queue taggin message. If the value of
> the byte is not 20h, 21h, 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.

The ESP driver explicitly clears this bit and only sets it for the
FAS236 variant (using it as fast clock bit there). The logic for setting
a target's config3 value refer to the stored config for target 0, and
the only place I can see that get initialized is again in esp_get_rev().
First to 5, then to 0 once it's clear the register even exists. We could
set bit 3 here, but it may not matter for the chip revisions that we are
interested in... Better set bit 6 (ESP_CONFIG3_TBMS) in our
esp_slave_configure() hook?

>
>>> I wonder why this problem didn't affect the old ESP driver? (Stan
>>> pointed out earlier in this thread that "Debian 3.1 (with a Linux
>>> 2.2.25 kernel) works on the Quadra 660av".)
>>
>> Yep, I wonder about the same thing. Changes to SCSI domain validation,
>> perhaps even not at the driver but mid level?
>
> Quite possible. I recall you said that you were able to resolve the issue
> with a patch to domain validation in the SCSI ML which would inhibit
> tagged queueing.
>
> But we really need David's patch, otherwise we probably end up with domain
> validation reporting a SCSI-2 device with the ESP left in SCSI-1 mode.

Yep, I agree. David's old patch doesn't apply anymore but it's quite
straightforward to reimplement.

>
>>
>> I vaguely recall that the old Mac ESP driver explicitly disabled
>> features like sync negotiation and perhaps others, and the interface to
>> do that had changed or disappeared after the 2.6 series? (No idea really
>> when that happened - my last interaction with the ESP driver would have
>> been almost 18 years ago. Totally different code.)
>
> The present mac_esp also disables sync transfers for PIO mode because I
> found that necessary. (Async PIO might be impossible.)
>
> printk(KERN_INFO PFX "using PIO for controller %d\n", dev->id);
> esp_write8(0, ESP_TCLOW);
> esp_write8(0, ESP_TCMED);
> esp->flags = ESP_FLAG_DISABLE_SYNC;
> mac_esp_ops.send_dma_cmd = mac_esp_send_pio_cmd;
>
> Tuomas reported that PIO instead of DMA did not affect the bug. But my
> recall is that the disk which would not work on my Quadra 660av (which
> uses PIO exclusively) did in fact work on a different kind of Quadra
> (which used PDMA, but also probably has different ESP silicon).
>
> Anyway, is safe to do this?
>
> esp->ops->send_dma_cmd(esp, esp->command_block_dma,
> 2, 2, 1, ESP_CMD_DMA | ESP_CMD_TI);
>
> /* ACK the message. */
> scsi_esp_cmd(esp, ESP_CMD_MOK);
>
> For PIO and PDMA, the transfer will be finished before the MOK ("Message
> Accepted") command, but for DMA this seems to be racey...

It sure is racey. Is there a DMA complete interrupt that you can wait
for before proceeding with the ACK?

Cheers,

Michael

[Michael Schmitz]

Hi Geert,

brain fade. sorry. Meant to say - depending on chip revision bit 3
takes a different semantics.

And yes, this is getting a wee bit technical. I just don't think we're
close to anything fit for review on linux-scsi.

Cheers,

Mchael

[Finn Thain]

On Mon, 31 Oct 2016, Michael Schmitz wrote:

> Am 30.10.2016 um 18:52 schrieb Finn Thain:
> >
> > On Sun, 30 Oct 2016, Michael Schmitz wrote:
> >
> > > but what makes the driver work with most disks but fail with some?
> > > Different SCSI command set supported by the disks?
> >
> > Anything that would inhibit disconnection/reselection should avoid the
> > bug. (BTW ISTR that my SCSI2SD never disconnects a command.)
> >
> > I think the target has to signal SEL-with-ATN during reselection in
> > order to trigger the bug. I think this is not part of SCSI-1.
> >
> > The SEL-with-ATN process is discussed in the "Configuration Register
> > 3" section, Bit 3, in
> > http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
>
> What chip revision is this doc for?

It can only be FAS100A. That's the document which David cited when he
posted his ESP_CONFIG2_SCSI2ENAB patch in 2014, which is why I was using
it. I think the documents Kars cited may be more relevant in this case:
http://www.spinics.net/lists/linux-scsi/msg73856.html
(those documents are all available from bitsavers).

> As far as I can make out, it should be fas100a? The esp_scsi.h comments
> suggest the tagged queuing bit is for revisions fas236. The chips used
> on Macs were probably esp236 or fas236? Depending on the

The Quadras I've used have ESP236 chips, according to esp_scsi detection.

>
> Not sure whether select with attention is present in SCSI-1,

I think SCSI-1 defines SEL-with-ATN for the initiator but not the target.
In this case (reselection) we have the target doing it.

That hook lets particular board-specific drivers disable particular
features for particular targets. It would be better, I think, to fix this
in the core driver, so that any target is free to use three byte messages
regardless of the board-specific driver (except ESP100 I guess).

Besides, ESP_CONFIG3_EWIDE == ESP_CONFIG3_TBMS, so this bit will get wiped
in esp_reset_cleanup() anyway. Probably this should be conditional on
FASHME. I think there's a similar bug in esp_data_bytes_sent().

That code comes from esp_reconnect_with_tag(). The interrupt you asked
about never shows up, hence, "Reconnect IRQ2 timeout".

Anyway, there must about 3 potential patches from this discussion. I say
we do as Geert suggests and move the discussion to the kernel.org lists
(with code, of course).

--

>
> Cheers,
>
> Michael
>
>