[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: esp_scsi, was Re: Modified Linux 4.1.20 (mac+scsi) on Quadra 660av

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 

> > 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...


Reply to: