[PATCH 0/2] Experimental Amiga Zorro ESP driver

[PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Geert,

other than 'it compiles', I can't really say much about this one. 
I've done what seemed necessary to do the ESP probe setup in the
zorro driver framework (using the NCR7xx driver as a guideline),  
and used the old Blizzard 2060 driver as a model for the DMA setup. 

To adapt to another style of ESP integration, the DMA setup function   
will need to be changed. The simplest way to cater for multipe boards    
in this driver may be to provide a separate DMA setup function for   
each, and substitute the correct one for the default esp_ops field in
the driver probe. Please correct me if you see a better or simpler way.

Posting to the list in the hope that someone will be able to compile
and test this. I will be increasingly busy at work over the next      
months, and may not have much opportunity to work on this until        
October. Ingo had offered a setup for remote debugging and testing,
but I've been slow to get started on that, and the machine now moves 
to FU Berlin if I understood right. 

Cheers,

        Michael

[PATCH 1/2] m68k/amiga - Zorro ESP SCSI Makefile/Kconfig support
[PATCH 2/2] m68k/amiga - Zorro ESP: convert old driver to ESP core

[PATCH 1/2] m68k/amiga - Zorro ESP SCSI Makefile/Kconfig support

[Michael Schmitz]

---
 drivers/scsi/Kconfig  |   16 ++++++++++++++++
 drivers/scsi/Makefile |    1 +
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index db95c54..8a08ee6 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1644,6 +1644,22 @@ config SCSI_ZORRO7XX
 	      accelerator card for the Amiga 1200,
 	    - the SCSI controller on the GVP Turbo 040/060 accelerator.
 
+config SCSI_ZORRO_ESP
+	tristate "Zorro ESP SCSI support"
+	depends on ZORRO && SCSI
+	select SCSI_SPI_ATTRS
+	help
+	  Support for various ESP-based SCSI controllers on Zorro
+	  expansion boards for the Amiga.
+	  This includes:
+	    - the Amiga 4091 Zorro III SCSI-2 controller,
+	    - the MacroSystem Development's WarpEngine Amiga SCSI-2 controller
+	      (info at
+	      <http://www.lysator.liu.se/amiga/ar/guide/ar310.guide?FEATURE5>),
+	    - the SCSI controller on the Phase5 Blizzard PowerUP 603e+
+	      accelerator card for the Amiga 1200,
+	    - the SCSI controller on the GVP Turbo 040/060 accelerator.
+
 config ATARI_SCSI
 	tristate "Atari native SCSI support"
 	depends on ATARI && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index b607ba4..487b8c5 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_INFINIBAND_ISER) 	+= libiscsi.o
 obj-$(CONFIG_ISCSI_BOOT_SYSFS)	+= iscsi_boot_sysfs.o
 obj-$(CONFIG_SCSI_A4000T)	+= 53c700.o	a4000t.o
 obj-$(CONFIG_SCSI_ZORRO7XX)	+= 53c700.o	zorro7xx.o
+obj-$(CONFIG_SCSI_ZORRO_ESP)	+= esp_scsi.o	zorro_esp.o
 obj-$(CONFIG_A3000_SCSI)	+= a3000.o	wd33c93.o
 obj-$(CONFIG_A2091_SCSI)	+= a2091.o	wd33c93.o
 obj-$(CONFIG_GVP11_SCSI)	+= gvp11.o	wd33c93.o
-- 
1.7.0.4

[PATCH 2/2] m68k/amiga - Zorro ESP: convert old driver to ESP core

[Michael Schmitz]

---
 drivers/scsi/zorro_esp.c |  414 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 414 insertions(+), 0 deletions(-)
 create mode 100644 drivers/scsi/zorro_esp.c

diff --git a/drivers/scsi/zorro_esp.c b/drivers/scsi/zorro_esp.c
new file mode 100644
index 0000000..b0d4a56
--- /dev/null
+++ b/drivers/scsi/zorro_esp.c
@@ -0,0 +1,414 @@
+/* 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/dma-mapping.h>
+#include <linux/scatterlist.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 "esp_scsi.h"
+
+MODULE_AUTHOR("Michael Schmitz <schmitz@debian.org>");
+MODULE_DESCRIPTION("Amiga Zorro NCR5C9x (ESP) driver");
+MODULE_LICENSE("GPL");
+
+
+static struct scsi_host_template zorro_esp_scsi_driver_template = {
+	.proc_name	= "zorro-esp",
+	.this_id	= 7,
+	.module		= THIS_MODULE,
+};
+
+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 },
+	{ .name = "CyberStormII", .offset = 0x1ff03, .dma_offset = 0x1ff43 },
+	{ .name = "Blizzard 2060", .offset = 0x1ff00, .dma_offset = 0x1ffe0 },
+	{ .name = "Blizzard 1230", .offset = 0x8000, .dma_offset = 0x10000 },
+	{ .name = "Blizzard 1230II", .offset = 0x10000, .dma_offset = 0x10021 },
+	{ .name = "Fastlane", .offset = 0x1000001, .dma_offset = 0x1000041, .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);
+
+/* The controller registers can be found in the Z2 config area at these
+ * offsets:
+ */
+#define BLZ2060_ESP_ADDR 0x1ff00
+#define BLZ2060_DMA_ADDR 0x1ffe0
+
+
+/* The Blizzard 2060 DMA interface
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * Only two things can be programmed in the Blizzard DMA:
+ *  1) The data direction is controlled by the status of bit 31 (1 = write)
+ *  2) The source/dest address (word aligned, shifted one right) in bits 30-0
+ *
+ * Figure out interrupt status by reading the ESP status byte.
+ */
+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] */
+};
+
+#define BLZ2060_DMA_WRITE 0x80000000
+
+/* 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 */
+}
+
+static void zorro_esp_send_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);
+
+	BUG_ON(!(cmd & ESP_CMD_DMA));
+	zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
+	zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
+
+	/* 
+	 * This will differ among Amiga ESP implementations - DMA setup!
+	 */
+
+	if (write)
+		cache_clear(addr, esp_count);
+	else
+		cache_push(addr, esp_count);
+
+	/* On the Sparc, DMA_ST_WRITE means "move data from device to memory"
+	 * so when (write) is true, it actually means READ (from the ESP)!
+	 */
+	addr >>= 1;
+	if (write)
+		addr &= ~(BLZ2060_DMA_WRITE);
+	else
+		addr |= BLZ2060_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, 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 const 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_dma_cmd,
+	.dma_error	=	zorro_esp_dma_error,
+};
+
+static int zorro_esp_init_one(struct zorro_dev *z,
+				       const struct zorro_device_id *ent)
+{
+	struct scsi_host_template *tpnt = &zorro_esp_scsi_driver_template;
+	struct Scsi_Host *host;
+	struct esp *esp;
+	struct zorro_driver_data *zdd;
+	unsigned long board, ioaddr, dmaaddr, esp_base;
+	int err = -ENOMEM;
+
+	board = zorro_resource_start(z);
+	zdd = (struct zorro_driver_data *)ent->driver_data;
+
+	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;
+	}
+
+	/* Fill in the required pieces of hostdata */
+	if (ioaddr > 0x01000000)
+		esp_base = ioremap(ioaddr, zorro_resource_len(z));
+	else
+		esp_base = (void __iomem *)ZTWO_VADDR(ioaddr);
+
+	zorro_esp_scsi_driver_template.name = zdd->name;
+
+	/* and register the chip */
+	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->max_id = 8;
+	esp = shost_priv(host);
+
+	esp->host = host;
+	esp->dev = z;
+	esp->ops = &zorro_esp_ops;
+
+	esp->regs = ioremap_nocache(ioaddr, 0x20);
+	if (!esp->regs)
+		goto fail_unmap_regs;
+
+	esp->dma_regs = ioremap_nocache(dmaaddr, 0x20);
+
+	esp->command_block = dma_alloc_coherent(esp->dev, 32,
+						&esp->command_block_dma,
+						GFP_KERNEL);
+	if (!esp->command_block)
+		goto fail_unmap_regs_dma;
+
+	host->irq = IRQ_AMIGA_PORTS;
+	err = request_irq(host->irq, scsi_esp_intr, IRQF_SHARED,
+			  "Amiga Zorro ESP", esp);
+	if (err < 0)
+		goto fail_unmap_command_block;
+
+	esp->scsi_id = 7;
+	esp->host->this_id = esp->scsi_id;
+	esp->scsi_id_mask = (1 << esp->scsi_id);
+	esp->cfreq = 20000000;
+
+	dev_set_drvdata(&z->dev, esp);
+
+	err = scsi_esp_register(esp, &z->dev);
+	if (err)
+		goto fail_free_irq;
+
+	zorro_set_drvdata(z, host);
+	scsi_scan_host(host);
+
+	return 0;
+
+fail_free_irq:
+	free_irq(host->irq, esp);
+fail_unmap_command_block:
+	dma_free_coherent(esp->dev, 16,
+			  esp->command_block,
+			  esp->command_block_dma);
+fail_unmap_regs_dma:
+	iounmap(esp->dma_regs);
+fail_unmap_regs:
+	iounmap(esp->regs);
+	scsi_host_put(host);
+out_free:
+	if (ioaddr > 0x01000000)
+		iounmap(esp_base);
+out_release:
+	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 = dev_get_drvdata(&z->dev);
+	unsigned int irq = esp->host->irq;
+	u32 val;
+
+	scsi_esp_unregister(esp);
+
+	/* Disable interrupts. Perhaps use disable_irq instead ... */
+
+	free_irq(irq, esp);
+	dma_free_coherent(esp->dev, 16,
+			  esp->command_block,
+			  esp->command_block_dma);
+
+	scsi_host_put(esp->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);
-- 
1.7.0.4

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 06/06/2013 11:56 PM, Michael Schmitz wrote:
> Geert,
>
> other than 'it compiles', I can't really say much about this one.
> I've done what seemed necessary to do the ESP probe setup in the
> zorro driver framework (using the NCR7xx driver as a guideline),
> and used the old Blizzard 2060 driver as a model for the DMA setup.
>
> To adapt to another style of ESP integration, the DMA setup function
> will need to be changed. The simplest way to cater for multipe boards
> in this driver may be to provide a separate DMA setup function for
> each, and substitute the correct one for the default esp_ops field in
> the driver probe. Please correct me if you see a better or simpler way.
Thank you for rewriting the driver.

I copypasted the appropriate DMA code from blz1230.c, and added some 
code to switch
to the appropriate function. I compiled the module, and was able to 
insert and remove it.

The dmesg output is attached. I also attached the modified zorro_esp.c.

There is a HDD attached to the SCSI bus, but the scan does not take place.

The chip on the controller is a FAS216, but it is identified as a 
FAS236. Does that matter?

-Tuomas

[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 3623 bytes --]

[-- Attachment #3: zorro_esp.c.gz --]
[-- Type: application/x-gzip, Size: 4136 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 08/16/2013 12:40 AM, Tuomas Vainikka wrote:
> On 06/06/2013 11:56 PM, Michael Schmitz wrote:
>> Geert,
>>
>> other than 'it compiles', I can't really say much about this one.
>> I've done what seemed necessary to do the ESP probe setup in the
>> zorro driver framework (using the NCR7xx driver as a guideline),
>> and used the old Blizzard 2060 driver as a model for the DMA setup.
>>
>> To adapt to another style of ESP integration, the DMA setup function
>> will need to be changed. The simplest way to cater for multipe boards
>> in this driver may be to provide a separate DMA setup function for
>> each, and substitute the correct one for the default esp_ops field in
>> the driver probe. Please correct me if you see a better or simpler way.
> Thank you for rewriting the driver.
>
> I copypasted the appropriate DMA code from blz1230.c, and added some 
> code to switch
> to the appropriate function. I compiled the module, and was able to 
> insert and remove it.
>
> The dmesg output is attached. I also attached the modified zorro_esp.c.
>
> There is a HDD attached to the SCSI bus, but the scan does not take 
> place.
>
> The chip on the controller is a FAS216, but it is identified as a 
> FAS236. Does that matter?
I got a little further, but now there seems to be something wrong with 
the IRQ:

[  297.720000] esp: esp0, regs[80ea8000:80eb0000] irq[2]
[  297.730000] esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
[  300.750000] scsi0 : esp
[  301.020000] scsi 0:0:1:0: Direct-Access     SAMSUNG SP1213N          
TL10 PQ: 0 ANSI: 2
[  301.030000] scsi target0:0:1: Beginning Domain Validation
[  301.060000] scsi target0:0:1: FAST-10 SCSI 10.0 MB/s ST (100 ns, 
offset 15)
[  301.090000] scsi target0:0:1: Domain Validation skipping write tests
[  301.100000] scsi target0:0:1: Ending Domain Validation
[  301.880000] esp: esp0: Reconnect IRQ2 timeout
[  332.040000] esp: esp0: Aborting command [0f9998a0:12]
[  332.040000] esp: esp0: Current command [0f999940:25]
[  332.040000] esp: esp0: Queued command [0f9998a0:12]
[  332.040000] esp: esp0: Active command [0f999940:25]
[  332.040000] esp: esp0: Dumping command log
...

I attached a full log containing the dmesg output from both probing and 
removing the module.

-Tuomas

[-- Attachment #2: zorro_esp.c.gz --]
[-- Type: application/x-gzip, Size: 4006 bytes --]

[-- Attachment #3: zorro_esp_modprobe2.cap.gz --]
[-- Type: application/x-gzip, Size: 4332 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

HelloTuomas,

> On 08/16/2013 12:40 AM, Tuomas Vainikka wrote:
>> On 06/06/2013 11:56 PM, Michael Schmitz wrote:
>>> Geert,
>>>
>>> other than 'it compiles', I can't really say much about this one.
>>> I've done what seemed necessary to do the ESP probe setup in the
>>> zorro driver framework (using the NCR7xx driver as a guideline),
>>> and used the old Blizzard 2060 driver as a model for the DMA setup.
>>>
>>> To adapt to another style of ESP integration, the DMA setup function
>>> will need to be changed. The simplest way to cater for multipe boards
>>> in this driver may be to provide a separate DMA setup function for
>>> each, and substitute the correct one for the default esp_ops field in
>>> the driver probe. Please correct me if you see a better or simpler 
>>> way.
>> Thank you for rewriting the driver.
>>
>> I copypasted the appropriate DMA code from blz1230.c, and added some 
>> code to switch
>> to the appropriate function. I compiled the module, and was able to 
>> insert and remove it.

Thanks, I will merge that with my current version of the driver. Thanks 
also for testing!

>>
>> The dmesg output is attached. I also attached the modified 
>> zorro_esp.c.
>>
>> There is a HDD attached to the SCSI bus, but the scan does not take 
>> place.
>>
>> The chip on the controller is a FAS216, but it is identified as a 
>> FAS236. Does that matter?

I would not think so - David Miller as author of the ESP core might 
know better though. The m68k mac esp driver is the only one I ever 
worked on - fifteen years ago.

> I got a little further, but now there seems to be something wrong with 
> the IRQ:
>
> [  297.720000] esp: esp0, regs[80ea8000:80eb0000] irq[2]
> [  297.730000] esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
> [  300.750000] scsi0 : esp
> [  301.020000] scsi 0:0:1:0: Direct-Access     SAMSUNG SP1213N         
>  TL10 PQ: 0 ANSI: 2
> [  301.030000] scsi target0:0:1: Beginning Domain Validation
> [  301.060000] scsi target0:0:1: FAST-10 SCSI 10.0 MB/s ST (100 ns, 
> offset 15)
> [  301.090000] scsi target0:0:1: Domain Validation skipping write tests
> [  301.100000] scsi target0:0:1: Ending Domain Validation
> [  301.880000] esp: esp0: Reconnect IRQ2 timeout

Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? It 
looks to me as though all DMA transfers fail (the first command to fail 
is READ_CAPACITY which would usually be issued right after IDENTIFY 
IIRC).

> [  332.040000] esp: esp0: Aborting command [0f9998a0:12]
> [  332.040000] esp: esp0: Current command [0f999940:25]
> [  332.040000] esp: esp0: Queued command [0f9998a0:12]
> [  332.040000] esp: esp0: Active command [0f999940:25]
> [  332.040000] esp: esp0: Dumping command log
> ...
>
> I attached a full log containing the dmesg output from both probing 
> and removing the module.

Thanks, I will try to make sense of the log...

Cheers,

	Michael


>
> -Tuomas
> <zorro_esp.c.gz><zorro_esp_modprobe2.cap.gz>

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

On 08/17/2013 04:49 AM, Michael Schmitz wrote:
>
>> [  301.880000] esp: esp0: Reconnect IRQ2 timeout
>
> Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? It 
> looks to me as though all DMA transfers fail (the first command to 
> fail is READ_CAPACITY which would usually be issued right after 
> IDENTIFY IIRC).

root@amiga:/# cat /proc/interrupts
            CPU0
   2:    1066320      auto  CIAA, zorro8390, ide0, Amiga Zorro ESP
   6:     456970      auto  CIAB
   8:      38239     amiga  serial TX
   9:          0     amiga  floppy_dma
  12:     315934     amiga  fb vertb handler
  13:     315741     amiga  serial status
  15:          0     amiga  DMA sound
  19:        401     amiga  serial RX
  23:          1       cia  floppy_timer
  25:          0       cia  amikbd
  27:     456971       cia  timer
ERR:          0

Seems like IRQ2 is very popular, so it's hard to say which device has 
generated the interrupts...
Should the assigned irq name match the module name?

-Tuomas

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Tuomas,
>>
>>> [  301.880000] esp: esp0: Reconnect IRQ2 timeout
>>
>> Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? 
>> It looks to me as though all DMA transfers fail (the first command to 
>> fail is READ_CAPACITY which would usually be issued right after 
>> IDENTIFY IIRC).
>
> root@amiga:/# cat /proc/interrupts
>            CPU0
>   2:    1066320      auto  CIAA, zorro8390, ide0, Amiga Zorro ESP
>   6:     456970      auto  CIAB
>   8:      38239     amiga  serial TX
>   9:          0     amiga  floppy_dma
>  12:     315934     amiga  fb vertb handler
>  13:     315741     amiga  serial status
>  15:          0     amiga  DMA sound
>  19:        401     amiga  serial RX
>  23:          1       cia  floppy_timer
>  25:          0       cia  amikbd
>  27:     456971       cia  timer
> ERR:          0
>
> Seems like IRQ2 is very popular, so it's hard to say which device has 
> generated the interrupts...

Yep - you'll be guaranteed to get a few IDE interrupts just by calling 
up cat - might be possible to get away without too much interrupts 
generated if it's all in the buffer cache - try whether the interrupt 
count changes after a few repetitions of that command.

Might require more elaborate IRQ bookkeeping though.

> Should the assigned irq name match the module name?
No, that's just the string passed to request_irq. I'm not aware of a 
policy mandating use of module names there.

Another question, after I had a look at your driver: are you certain 
mapping a size of 0x20 is enough for the Mark IV DMA engine? The latch 
register is at offset 0x8000 from the address register ...

All (or most) other ESP drivers use 16 bit transfer counts only - you 
set the 1230 to use 24 bit, can it actually do that?

Cheers,

    Michael

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Geert Uytterhoeven]

On Sun, Aug 18, 2013 at 4:05 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>>>> [  301.880000] esp: esp0: Reconnect IRQ2 timeout

Beware that this message (incl. the number) is hardcoded in
drivers/scsi/esp_scsi.c:

        if (i == ESP_RESELECT_TAG_LIMIT) {
                printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n",
                       esp->host->unique_id);
                return NULL;
        }

The driver prints "IRQ1" or "IRQ2".

Fortunately, IRQ_AMIGA_PORTS is 2, but this is purely coincidentally...

>>> Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? It
>>> looks to me as though all DMA transfers fail (the first command to fail is
>>> READ_CAPACITY which would usually be issued right after IDENTIFY IIRC).
>>
>> root@amiga:/# cat /proc/interrupts
>>            CPU0
>>   2:    1066320      auto  CIAA, zorro8390, ide0, Amiga Zorro ESP
>>   6:     456970      auto  CIAB
>>   8:      38239     amiga  serial TX
>>   9:          0     amiga  floppy_dma
>>  12:     315934     amiga  fb vertb handler
>>  13:     315741     amiga  serial status
>>  15:          0     amiga  DMA sound
>>  19:        401     amiga  serial RX
>>  23:          1       cia  floppy_timer
>>  25:          0       cia  amikbd
>>  27:     456971       cia  timer
>> ERR:          0
>>
>> Seems like IRQ2 is very popular, so it's hard to say which device has
>> generated the interrupts...
>
>
> Yep - you'll be guaranteed to get a few IDE interrupts just by calling up
> cat - might be possible to get away without too much interrupts generated if
> it's all in the buffer cache - try whether the interrupt count changes after
> a few repetitions of that command.
>
> Might require more elaborate IRQ bookkeeping though.

I guess scsi_esp_intr() is called a lot, as it's a shared interrupt?
Can you add some debug prints there, to see if any of the conditions the
esp core checks are met?

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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Geert,
> On Sun, Aug 18, 2013 at 4:05 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>   
>>>>> [  301.880000] esp: esp0: Reconnect IRQ2 timeout
>>>>>           
>
> Beware that this message (incl. the number) is hardcoded in
> drivers/scsi/esp_scsi.c:
>
>         if (i == ESP_RESELECT_TAG_LIMIT) {
>                 printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n",
>                        esp->host->unique_id);
>                 return NULL;
>         }
>
> The driver prints "IRQ1" or "IRQ2".
>
> Fortunately, IRQ_AMIGA_PORTS is 2, but this is purely coincidentally...
>   

The driver attempts to DMA two bytes - can the DMA on the Zorro ESP 
cards handle such short transfers?

I'll also need to check the command_block and command_block_dma 
addresses - does the DMA require virtual or physical addresses?

>   
>>>> Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? It
>>>> looks to me as though all DMA transfers fail (the first command to fail is
>>>> READ_CAPACITY which would usually be issued right after IDENTIFY IIRC).
>>>>         
>>> root@amiga:/# cat /proc/interrupts
>>>            CPU0
>>>   2:    1066320      auto  CIAA, zorro8390, ide0, Amiga Zorro ESP
>>>   6:     456970      auto  CIAB
>>>   8:      38239     amiga  serial TX
>>>   9:          0     amiga  floppy_dma
>>>  12:     315934     amiga  fb vertb handler
>>>  13:     315741     amiga  serial status
>>>  15:          0     amiga  DMA sound
>>>  19:        401     amiga  serial RX
>>>  23:          1       cia  floppy_timer
>>>  25:          0       cia  amikbd
>>>  27:     456971       cia  timer
>>> ERR:          0
>>>
>>> Seems like IRQ2 is very popular, so it's hard to say which device has
>>> generated the interrupts...
>>>       
>> Yep - you'll be guaranteed to get a few IDE interrupts just by calling up
>> cat - might be possible to get away without too much interrupts generated if
>> it's all in the buffer cache - try whether the interrupt count changes after
>> a few repetitions of that command.
>>
>> Might require more elaborate IRQ bookkeeping though.
>>     
>
> I guess scsi_esp_intr() is called a lot, as it's a shared interrupt?
>   

That's right - it will indeed be called a lot.

> Can you add some debug prints there, to see if any of the conditions the
> esp core checks are met?
>   
The code in question polls for completion in the ESP chip interrupt 
register, so checking in scsi_esp_intr won't help there. I suspect the 
ESP gets stuck because the DMA operation never completes. Wonder whether 
we can just do PIO in send_dma_cmd() in these cases ...

Cheers,

    Michael

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Geert Uytterhoeven]

On Sun, Aug 18, 2013 at 10:58 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> I'll also need to check the command_block and command_block_dma addresses -
> does the DMA require virtual or physical addresses?

Physical, of course.

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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 08/18/2013 11:58 AM, Michael Schmitz wrote:
> Geert,
>> On Sun, Aug 18, 2013 at 4:05 AM, Michael Schmitz 
>> <schmitzmic@gmail.com> wrote:
>>>>>> [  301.880000] esp: esp0: Reconnect IRQ2 timeout
>>
>> Beware that this message (incl. the number) is hardcoded in
>> drivers/scsi/esp_scsi.c:
>>
>>         if (i == ESP_RESELECT_TAG_LIMIT) {
>>                 printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n",
>>                        esp->host->unique_id);
>>                 return NULL;
>>         }
>>
>> The driver prints "IRQ1" or "IRQ2".
>>
>> Fortunately, IRQ_AMIGA_PORTS is 2, but this is purely coincidentally...
>
> The driver attempts to DMA two bytes - can the DMA on the Zorro ESP 
> cards handle such short transfers?
>
> I'll also need to check the command_block and command_block_dma 
> addresses - does the DMA require virtual or physical addresses?
>
>>>>> Are there interrupts logged for IRQ2 at all (cat 
>>>>> /proc/interrupts)? It
>>>>> looks to me as though all DMA transfers fail (the first command to 
>>>>> fail is
>>>>> READ_CAPACITY which would usually be issued right after IDENTIFY 
>>>>> IIRC).
>>>> root@amiga:/# cat /proc/interrupts
>>>>            CPU0
>>>>   2:    1066320      auto  CIAA, zorro8390, ide0, Amiga Zorro ESP
>>>>   6:     456970      auto  CIAB
>>>>   8:      38239     amiga  serial TX
>>>>   9:          0     amiga  floppy_dma
>>>>  12:     315934     amiga  fb vertb handler
>>>>  13:     315741     amiga  serial status
>>>>  15:          0     amiga  DMA sound
>>>>  19:        401     amiga  serial RX
>>>>  23:          1       cia  floppy_timer
>>>>  25:          0       cia  amikbd
>>>>  27:     456971       cia  timer
>>>> ERR:          0
>>>>
>>>> Seems like IRQ2 is very popular, so it's hard to say which device has
>>>> generated the interrupts...
>>> Yep - you'll be guaranteed to get a few IDE interrupts just by 
>>> calling up
>>> cat - might be possible to get away without too much interrupts 
>>> generated if
>>> it's all in the buffer cache - try whether the interrupt count 
>>> changes after
>>> a few repetitions of that command.
>>>
>>> Might require more elaborate IRQ bookkeeping though.
>>
>> I guess scsi_esp_intr() is called a lot, as it's a shared interrupt?
>
> That's right - it will indeed be called a lot.
>
>> Can you add some debug prints there, to see if any of the conditions the
>> esp core checks are met?
> The code in question polls for completion in the ESP chip interrupt 
> register, so checking in scsi_esp_intr won't help there. I suspect the 
> ESP gets stuck because the DMA operation never completes. Wonder 
> whether we can just do PIO in send_dma_cmd() in these cases ...
>
The original blz1230 / blz2060 drivers did PIO commands. I attached a 
log of modprobing first without interrupt messages and then with the 
interrupt messages, because, indeed, the zorro_esp_irq_pending function 
gets called a lot, and it takes forever to printk those messages. I have 
no idea about the correct iomappings for the registers, nor do I know 
about the correct sizes for them. I have no idea where to use physical 
addresses and where to use virtual addresses...

What is the difference between ioremap() and ZTWO_VADDR() and which one 
should be used where?

-Tuomas


[-- Attachment #2: zorro_esp.c.gz --]
[-- Type: application/x-gzip, Size: 4236 bytes --]

[-- Attachment #3: zesp001.cap.gz --]
[-- Type: application/x-gzip, Size: 3531 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Geert Uytterhoeven]

On Sun, Aug 18, 2013 at 11:14 AM, Tuomas Vainikka
<tuomas.vainikka@aalto.fi> wrote:
> The original blz1230 / blz2060 drivers did PIO commands. I attached a log of
> modprobing first without interrupt messages and then with the interrupt
> messages, because, indeed, the zorro_esp_irq_pending function gets called a
> lot, and it takes forever to printk those messages. I have no idea about the

You can use WARN_RATELIMIT() instead to avoid flooding the screen
with the same values.
printk_ratelimit() is similar, but it uses a single instance of the
ratelimit state,
i.e. you cannot use it to limit two different value sets.

> correct iomappings for the registers, nor do I know about the correct sizes
> for them. I have no idea where to use physical addresses and where to use
> virtual addresses...

When the CPU accesses memory, you have to use virtual addresses.
When the DMA engine accesses memory, it has to use physical addresses.

Typically the DMA API is used to do the conversion
> What is the difference between ioremap() and ZTWO_VADDR() and which one
> should be used where?

ioremap() is the generic way to map hardware registers into the CPU's virtual
address space.

As the 16 MiB Zorro II address space is always mapped, you can use
ZTWO_VADDR() for Zorro II addresses instead. This macro converts from
physical Zorro II addresses to virtual kernel addresses.

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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 08/18/2013 12:42 PM, Geert Uytterhoeven wrote:
> On Sun, Aug 18, 2013 at 11:14 AM, Tuomas Vainikka
> <tuomas.vainikka@aalto.fi> wrote:
>> The original blz1230 / blz2060 drivers did PIO commands. I attached a log of
>> modprobing first without interrupt messages and then with the interrupt
>> messages, because, indeed, the zorro_esp_irq_pending function gets called a
>> lot, and it takes forever to printk those messages. I have no idea about the
> You can use WARN_RATELIMIT() instead to avoid flooding the screen
> with the same values.
> printk_ratelimit() is similar, but it uses a single instance of the
> ratelimit state,
> i.e. you cannot use it to limit two different value sets.
>
>
Ok, here's the suppressed output. Like Michael said, the short DMA 
command seems to be the problem, and should probably be sent using PIO.

-Tuomas

[-- Attachment #2: zesp004.cap.gz --]
[-- Type: application/x-gzip, Size: 3467 bytes --]

[-- Attachment #3: zorro_esp.c.gz --]
[-- Type: application/x-gzip, Size: 4314 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Geert,
> On Sun, Aug 18, 2013 at 10:58 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>   
>> I'll also need to check the command_block and command_block_dma addresses -
>> does the DMA require virtual or physical addresses?
>>     
>
> Physical, of course.
>   

:-) VDMA was invented a bit later ...


I'll go check the usage of the DMA API calls again, but as the driver 
seems to do DMA fine until the short transfer, that seems the most 
likely cause. PIO for dma_count < 7 might be an option.

I see transfers with esp_count=1 and dma_count=7 in the log - wonder why 
that works but the short 2/2 byte case does not.

Cheers,

    Michael

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

On 08/19/2013 11:48 AM, Michael Schmitz wrote:
> Geert,
>> On Sun, Aug 18, 2013 at 10:58 AM, Michael Schmitz 
>> <schmitzmic@gmail.com> wrote:
>>> I'll also need to check the command_block and command_block_dma 
>>> addresses -
>>> does the DMA require virtual or physical addresses?
>>
>> Physical, of course.
>
> :-) VDMA was invented a bit later ...
>
>
> I'll go check the usage of the DMA API calls again, but as the driver 
> seems to do DMA fine until the short transfer, that seems the most 
> likely cause. PIO for dma_count < 7 might be an option.
>
> I see transfers with esp_count=1 and dma_count=7 in the log - wonder 
> why that works but the short 2/2 byte case does not.
>
Is it possible that the problem is with memory alignment?

http://fxr.watson.org/fxr/source/arch/amiga/dev/bzivsc.c?v=NETBSD#L360
https://groups.google.com/d/msg/comp.sys.amiga.hardware/FXwaSFoAPxc/zsXeP7PB6RoJ

-Tuomas

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Geert Uytterhoeven]

On Mon, Aug 19, 2013 at 1:47 PM, Tuomas Vainikka
<tuomas.vainikka@aalto.fi> wrote:
> Is it possible that the problem is with memory alignment?

Not here:

[ 2549.540000] zorro_esp: esp_count = 2,  dma_count = 2, addr =
0x7fbe1000. Writing.
[ 2549.540000] esp: esp0: Reconnect IRQ2 timeout

addr = 0x7fbe1000, which is even PAGE_SIZE aligned.

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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 08/19/2013 11:48 AM, Michael Schmitz wrote:
> Geert,
>> On Sun, Aug 18, 2013 at 10:58 AM, Michael Schmitz 
>> <schmitzmic@gmail.com> wrote:
>>> I'll also need to check the command_block and command_block_dma 
>>> addresses -
>>> does the DMA require virtual or physical addresses?
>>
>> Physical, of course.
>
> :-) VDMA was invented a bit later ...
>
>
> I'll go check the usage of the DMA API calls again, but as the driver 
> seems to do DMA fine until the short transfer, that seems the most 
> likely cause. PIO for dma_count < 7 might be an option.
>
> I see transfers with esp_count=1 and dma_count=7 in the log - wonder 
> why that works but the short 2/2 byte case does not.
>
> Cheers,
>
>    Michael
>
I guess those two bytes have something to do with target 
(re)selection... There are two different ways of attempting to read 
these bytes in the code, one is reading them from the FIFO byte by byte, 
and the other way is to setup a DMA read (write from device). The two 
different schemes are used in two different functions, and I do not 
understand why one method would be preferred over the other when 
comparing these functions.

I think I managed to find these two bytes; They are not ready for DMA, 
but are sitting in the FIFO waiting to be read.
So the loop before the "IRQ2 timeout" is waiting for an interrupt that 
would tell that the DMA transfer has finished.
...

[13433.390000] ESP: Disconnecting tgt[1] tag[20:0]
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x97, 2 bytes in FIFO.
[13433.400000] ESP: intr sreg[97] seqreg[04] sreg2[00] ireg[0c]
[13433.400000] ESP: reconnect tag, zorro_esp_irq_pending(): ESP_STATUS = 
0x97, 0 bytes in FIFO.
[13433.400000] IRQ(0:10:97), zorro_esp: esp_count = 2,  dma_count = 2, 
addr = 0x7fa59000. Writing.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
[13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
...
Remember that write is read :)

Now, I guess, I have to check whether those two bytes contain the right 
information...

-Tuomas

[-- Attachment #2: zesp014.cap.gz --]
[-- Type: application/x-gzip, Size: 2722 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Tuomas,

> I guess those two bytes have something to do with target 
> (re)selection... There are two different ways of attempting to read 
> these bytes in the code, one is reading them from the FIFO byte by 
> byte, and the other way is to setup a DMA read (write from device). 
> The two different schemes are used in two different functions, and I 
> do not understand why one method would be preferred over the other 
> when comparing these functions.

What the driver attempts to read on reselection are the tag bytes that 
were used in the previous disconnect. These have to match otherwise we 
are not reselecting the command we need.

No idea which functions you refer to regarding PIO (reading from FIFO). 
Anyway, the DMA will read from the same FIFO that the CPU would, if I 
understand DMA correctly. There really should be no difference-

> I think I managed to find these two bytes; They are not ready for DMA, 
> but are sitting in the FIFO waiting to be read.
> So the loop before the "IRQ2 timeout" is waiting for an interrupt that 
> would tell that the DMA transfer has finished.

The loop checks whether the ESP status indicates the transfer is done - 
if the bytes are still stuck in the FIFO I'd guess the DMA does not 
bother to transfer for such small transfer counts.

The DMA transfer function can be changed to fetch less than seven bytes 
from the FIFO by PIO instead of setting up DMA transfer (just poll the 
FIFO after sending the command to the ESP, instead of first setting up 
the DMA then sending the command),

I haven't yet merged your changes into my source - will try to do that 
tomorrow.

Cheers,

	Michael


> ...
>
> [13433.390000] ESP: Disconnecting tgt[1] tag[20:0]
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x97, 2 bytes in 
> FIFO.
> [13433.400000] ESP: intr sreg[97] seqreg[04] sreg2[00] ireg[0c]
> [13433.400000] ESP: reconnect tag, zorro_esp_irq_pending(): ESP_STATUS 
> = 0x97, 0 bytes in FIFO.
> [13433.400000] IRQ(0:10:97), zorro_esp: esp_count = 2,  dma_count = 2, 
> addr = 0x7fa59000. Writing.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in 
> FIFO.
> ...
> Remember that write is read :)
>
> Now, I guess, I have to check whether those two bytes contain the 
> right information...
>
> -Tuomas
> <zesp014.cap.gz>

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

On 08/20/2013 12:36 PM, Michael Schmitz wrote:
> Tuomas,
>
>> I guess those two bytes have something to do with target 
>> (re)selection... There are two different ways of attempting to read 
>> these bytes in the code, one is reading them from the FIFO byte by 
>> byte, and the other way is to setup a DMA read (write from device). 
>> The two different schemes are used in two different functions, and I 
>> do not understand why one method would be preferred over the other 
>> when comparing these functions.
>
> What the driver attempts to read on reselection are the tag bytes that 
> were used in the previous disconnect. These have to match otherwise we 
> are not reselecting the command we need.
>
> No idea which functions you refer to regarding PIO (reading from 
> FIFO). Anyway, the DMA will read from the same FIFO that the CPU 
> would, if I understand DMA correctly. There really should be no 
> difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
>
>> I think I managed to find these two bytes; They are not ready for 
>> DMA, but are sitting in the FIFO waiting to be read.
>> So the loop before the "IRQ2 timeout" is waiting for an interrupt 
>> that would tell that the DMA transfer has finished.
>
> The loop checks whether the ESP status indicates the transfer is done 
> - if the bytes are still stuck in the FIFO I'd guess the DMA does not 
> bother to transfer for such small transfer counts.
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)

explains why the bytes might end up in FIFO; The chip DMA got disabled 
at some point. Also, you need to explicitly issue a specific (don't know 
which, yet) command to let the DMA access the FIFO.
>
> The DMA transfer function can be changed to fetch less than seven 
> bytes from the FIFO by PIO instead of setting up DMA transfer (just 
> poll the FIFO after sending the command to the ESP, instead of first 
> setting up the DMA then sending the command),
>
I'd rather find out why and where the DMA is disabled before we resort 
to PIO. It is also possible that the chip interrupt is cleared 
prematurely by reading the interrupt register, in which case the 
interrupt is not seen by  The Loop.

-Tuomas

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Hello Tuomas,

>> No idea which functions you refer to regarding PIO (reading from FIFO).
>> Anyway, the DMA will read from the same FIFO that the CPU would, if I
>> understand DMA correctly. There really should be no difference-
>
> esp.scsi.c:1058 versus esp.scsi.c:1120

I suppose this is because reconnect_with_tag() cannot rely on the tag
information already being in the FIFO when it is called from
esp_reconnect(). esp_reconnect() is called from the reselection
interrupt so the fifo data is already present.

> In:
> http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
> page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
>
> explains why the bytes might end up in FIFO; The chip DMA got disabled at
> some point. Also, you need to explicitly issue a specific (don't know which,
> yet) command to let the DMA access the FIFO.

The chip DMA should be activated by the ESP_CMD_DMA bit that is set in
all uses of send_dma_cmd. I can't see where the DMA would have been
disabled.

>> The DMA transfer function can be changed to fetch less than seven bytes
>> from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
>> after sending the command to the ESP, instead of first setting up the DMA
>> then sending the command),
>>
> I'd rather find out why and where the DMA is disabled before we resort to
> PIO. It is also possible that the chip interrupt is cleared prematurely by
> reading the interrupt register, in which case the interrupt is not seen by
> The Loop.

That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.

David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.

Cheers,

  Michael




On Tue, Aug 20, 2013 at 10:00 PM, Tuomas Vainikka
<tuomas.vainikka@aalto.fi> wrote:
> On 08/20/2013 12:36 PM, Michael Schmitz wrote:
>>
>> Tuomas,
>>
>>> I guess those two bytes have something to do with target (re)selection...
>>> There are two different ways of attempting to read these bytes in the code,
>>> one is reading them from the FIFO byte by byte, and the other way is to
>>> setup a DMA read (write from device). The two different schemes are used in
>>> two different functions, and I do not understand why one method would be
>>> preferred over the other when comparing these functions.
>>
>>
>> What the driver attempts to read on reselection are the tag bytes that
>> were used in the previous disconnect. These have to match otherwise we are
>> not reselecting the command we need.
>>
>> No idea which functions you refer to regarding PIO (reading from FIFO).
>> Anyway, the DMA will read from the same FIFO that the CPU would, if I
>> understand DMA correctly. There really should be no difference-
>
> esp.scsi.c:1058 versus esp.scsi.c:1120
>
>>
>>> I think I managed to find these two bytes; They are not ready for DMA,
>>> but are sitting in the FIFO waiting to be read.
>>> So the loop before the "IRQ2 timeout" is waiting for an interrupt that
>>> would tell that the DMA transfer has finished.
>>
>>
>> The loop checks whether the ESP status indicates the transfer is done - if
>> the bytes are still stuck in the FIFO I'd guess the DMA does not bother to
>> transfer for such small transfer counts.
>
> In:
> http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
> page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
>
> explains why the bytes might end up in FIFO; The chip DMA got disabled at
> some point. Also, you need to explicitly issue a specific (don't know which,
> yet) command to let the DMA access the FIFO.
>
>>
>> The DMA transfer function can be changed to fetch less than seven bytes
>> from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
>> after sending the command to the ESP, instead of first setting up the DMA
>> then sending the command),
>>
> I'd rather find out why and where the DMA is disabled before we resort to
> PIO. It is also possible that the chip interrupt is cleared prematurely by
> reading the interrupt register, in which case the interrupt is not seen by
> The Loop.
>
> -Tuomas

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 08/22/2013 11:34 PM, Michael Schmitz wrote:
> Hello Tuomas,
>
>>> No idea which functions you refer to regarding PIO (reading from FIFO).
>>> Anyway, the DMA will read from the same FIFO that the CPU would, if I
>>> understand DMA correctly. There really should be no difference-
>> esp.scsi.c:1058 versus esp.scsi.c:1120
> I suppose this is because reconnect_with_tag() cannot rely on the tag
> information already being in the FIFO when it is called from
> esp_reconnect(). esp_reconnect() is called from the reselection
> interrupt so the fifo data is already present.
>
>> In:
>> http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
>> page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
>>
>> explains why the bytes might end up in FIFO; The chip DMA got disabled at
>> some point. Also, you need to explicitly issue a specific (don't know which,
>> yet) command to let the DMA access the FIFO.
> The chip DMA should be activated by the ESP_CMD_DMA bit that is set in
> all uses of send_dma_cmd. I can't see where the DMA would have been
> disabled.
>
>>> The DMA transfer function can be changed to fetch less than seven bytes
>>> from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
>>> after sending the command to the ESP, instead of first setting up the DMA
>>> then sending the command),
>>>
>> I'd rather find out why and where the DMA is disabled before we resort to
>> PIO. It is also possible that the chip interrupt is cleared prematurely by
>> reading the interrupt register, in which case the interrupt is not seen by
>> The Loop.
> That's the attitude - my suggestion was purely pragmatic, in order to
> overcome that particular roadblock and see whether there's further
> issues. But fixing this properly would be much preferred.
>
> David Miller is still maintainer of the ESP code - I can't think of
> anyone better suited to answer ESP specific questions really.
>
>
This might have nothing to do with the current issue, but during the 
course of debugging this two byte dma write, I stumbled across this;

[ 2434.370000] ESP: reconnect tag, IRQ(0:10:97), kernel BUG at 
mm/slab.c:3011! [1]

I had modified the code in esp_scsi.c inside the reconnect_with_tag 
function to kzalloc the two bytes, single mapping it to "from device" 
direction in order to check whether the issue was with the dma writing 
directly to the command block. The dma command was directed to write the 
two bytes to the area kalloc'd, after which they were copied to the real 
command block, and the kalloc'd area was unmapped and freed. This would 
work a couple times when the driver attempted to get the two bytes, but 
eventually, the above mentioned kernel bug would kick in. I had made 
sure to unmap and free the two bytes before the function could exit.

Another oddity [2] was that I assigned the kalloc'd bytes to 0xff and 
0xfe, and although the code to copy the two bytes to the real command 
block was after the IRQ2 timeout loop (that continuously calls 
zorro_esp_irq_pending() ), these values were already sitting in the 
command block before the loop would exit and the values be copied. I 
could not prevent this from happening even when I disabled optimizations 
and/or made the copy through a temporary volatile u8. The last two 
values from the printk are command_block[0] and command_block[1].

[1] zesp050.cap:836 (printk message in zorro_esp_irq_pending() was disabled)
[2] zesp049.cap:988

-Tuomas

[-- Attachment #2: zesp049.cap.gz --]
[-- Type: application/x-gzip, Size: 4570 bytes --]

[-- Attachment #3: zesp050.cap.gz --]
[-- Type: application/x-gzip, Size: 10753 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 08/22/2013 11:34 PM, Michael Schmitz wrote:
> Hello Tuomas,
>
>>> No idea which functions you refer to regarding PIO (reading from FIFO).
>>> Anyway, the DMA will read from the same FIFO that the CPU would, if I
>>> understand DMA correctly. There really should be no difference-
>> esp.scsi.c:1058 versus esp.scsi.c:1120
> I suppose this is because reconnect_with_tag() cannot rely on the tag
> information already being in the FIFO when it is called from
> esp_reconnect(). esp_reconnect() is called from the reselection
> interrupt so the fifo data is already present.
>
>> In:
>> http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
>> page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
>>
>> explains why the bytes might end up in FIFO; The chip DMA got disabled at
>> some point. Also, you need to explicitly issue a specific (don't know which,
>> yet) command to let the DMA access the FIFO.
> The chip DMA should be activated by the ESP_CMD_DMA bit that is set in
> all uses of send_dma_cmd. I can't see where the DMA would have been
> disabled.
>
>>> The DMA transfer function can be changed to fetch less than seven bytes
>>> from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
>>> after sending the command to the ESP, instead of first setting up the DMA
>>> then sending the command),
>>>
>> I'd rather find out why and where the DMA is disabled before we resort to
>> PIO. It is also possible that the chip interrupt is cleared prematurely by
>> reading the interrupt register, in which case the interrupt is not seen by
>> The Loop.
> That's the attitude - my suggestion was purely pragmatic, in order to
> overcome that particular roadblock and see whether there's further
> issues. But fixing this properly would be much preferred.
>
> David Miller is still maintainer of the ESP code - I can't think of
> anyone better suited to answer ESP specific questions really.
>
> Cheers,
>
>    Michael
>
I got it to work. Somehow, at least. I wrote the driver to use PIO for 
command block reads and writes, and found out that it didn't fix the 
problem. Using PIO, only the first byte of the tag message comes 
through. It might not be esp_scsi's fault, but there seems to be an 
assumption that all devices support TCQ. Also, no SCSI-2 features seem 
to be enabled in the chip by esp_scsi.

To cut the long story short, I hardwired TCQ off with a replacement 
function for esp_slave_configure().
The replacement function resides in zorro_esp.c and is essentially doing 
the same thing as the original if ESP_DEFAULT_TAGS was set to zero in 
esp_scsi.h.

There is no need for PIO with the above hack.

I've attached a log of the module loading and some operations on the 
attached hdd. Note that there are messages such as

[ 4627.040000] sd 0:0:0:0: [sda] Got wrong page
and
[ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.

which don't seem normal.

-Tuomas


[-- Attachment #2: zesp161.cap.gz --]
[-- Type: application/x-gzip, Size: 2535 bytes --]

[-- Attachment #3: zorro_esp.c.gz --]
[-- Type: application/x-gzip, Size: 4484 bytes --]

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Hello Tuomas,

>> That's the attitude - my suggestion was purely pragmatic, in order to
>> overcome that particular roadblock and see whether there's further
>> issues. But fixing this properly would be much preferred.
>>
>> David Miller is still maintainer of the ESP code - I can't think of
>> anyone better suited to answer ESP specific questions really.
>>
>> Cheers,
>>
>>    Michael
>>
> I got it to work. Somehow, at least. I wrote the driver to use PIO for
> command block reads and writes, and found out that it didn't fix the

Thanks, that does indeed absolve DMA.

> problem. Using PIO, only the first byte of the tag message comes through. It
> might not be esp_scsi's fault, but there seems to be an assumption that all
> devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip
> by esp_scsi.

I'd have to check with DaveM, but such an assumption might in fact exist.

SCSI-2 features might have been disabled in response to your disk's
response in the device configure phase. Maybe someone with a newer
SCSI disk (one that does support TCQ from scratch, and the full SCSI-2
command set or better) should try the original driver sometime.

What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
higher? (Apologies for asking this - it will be in one of your old
logs but I cannot easily read these here.)

> To cut the long story short, I hardwired TCQ off with a replacement function
> for esp_slave_configure().
> The replacement function resides in zorro_esp.c and is essentially doing the
> same thing as the original if ESP_DEFAULT_TAGS was set to zero in
> esp_scsi.h.
>
> There is no need for PIO with the above hack.

That's a good start - now can anyone remember whether the old Zorro
ESP drivers ever used or supported tagged commands? I would not want
to hassle DaveM for something that never worked before.

If we can find out how to detect that TCQ is unsupported, Dave could
splice that into the core esp_slave_configure() and solve our problem.

> I've attached a log of the module loading and some operations on the
> attached hdd. Note that there are messages such as
>
> [ 4627.040000] sd 0:0:0:0: [sda] Got wrong page
> and
> [ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.

WRITE SAME might be unsupported by your device (guessing, I could not
find out where the message originates from). The 'got wrong page' I
had to look up, but it also appears to be a case of unsupported
feature.

> which don't seem normal.

The acid test is - did it destroy your filesystem?

If not, I'd say you did brilliantly.

Thanks again,

  Michael



On Tue, Sep 10, 2013 at 11:13 PM, Tuomas Vainikka
<tuomas.vainikka@aalto.fi> wrote:
> On 08/22/2013 11:34 PM, Michael Schmitz wrote:
>>
>> Hello Tuomas,
>>
>>>> No idea which functions you refer to regarding PIO (reading from FIFO).
>>>> Anyway, the DMA will read from the same FIFO that the CPU would, if I
>>>> understand DMA correctly. There really should be no difference-
>>>
>>> esp.scsi.c:1058 versus esp.scsi.c:1120
>>
>> I suppose this is because reconnect_with_tag() cannot rely on the tag
>> information already being in the FIFO when it is called from
>> esp_reconnect(). esp_reconnect() is called from the reselection
>> interrupt so the fifo data is already present.
>>
>>> In:
>>> http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
>>> page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
>>>
>>> explains why the bytes might end up in FIFO; The chip DMA got disabled at
>>> some point. Also, you need to explicitly issue a specific (don't know
>>> which,
>>> yet) command to let the DMA access the FIFO.
>>
>> The chip DMA should be activated by the ESP_CMD_DMA bit that is set in
>> all uses of send_dma_cmd. I can't see where the DMA would have been
>> disabled.
>>
>>>> The DMA transfer function can be changed to fetch less than seven bytes
>>>> from the FIFO by PIO instead of setting up DMA transfer (just poll the
>>>> FIFO
>>>> after sending the command to the ESP, instead of first setting up the
>>>> DMA
>>>> then sending the command),
>>>>
>>> I'd rather find out why and where the DMA is disabled before we resort to
>>> PIO. It is also possible that the chip interrupt is cleared prematurely
>>> by
>>> reading the interrupt register, in which case the interrupt is not seen
>>> by
>>> The Loop.
>>
>> That's the attitude - my suggestion was purely pragmatic, in order to
>> overcome that particular roadblock and see whether there's further
>> issues. But fixing this properly would be much preferred.
>>
>> David Miller is still maintainer of the ESP code - I can't think of
>> anyone better suited to answer ESP specific questions really.
>>
>> Cheers,
>>
>>    Michael
>>
> I got it to work. Somehow, at least. I wrote the driver to use PIO for
> command block reads and writes, and found out that it didn't fix the
> problem. Using PIO, only the first byte of the tag message comes through. It
> might not be esp_scsi's fault, but there seems to be an assumption that all
> devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip
> by esp_scsi.
>
> To cut the long story short, I hardwired TCQ off with a replacement function
> for esp_slave_configure().
> The replacement function resides in zorro_esp.c and is essentially doing the
> same thing as the original if ESP_DEFAULT_TAGS was set to zero in
> esp_scsi.h.
>
> There is no need for PIO with the above hack.
>
> I've attached a log of the module loading and some operations on the
> attached hdd. Note that there are messages such as
>
> [ 4627.040000] sd 0:0:0:0: [sda] Got wrong page
> and
> [ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.
>
> which don't seem normal.
>
> -Tuomas
>

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

On 09/11/2013 01:12 PM, Michael Schmitz wrote:
> Hello Tuomas,
>
>>> That's the attitude - my suggestion was purely pragmatic, in order to
>>> overcome that particular roadblock and see whether there's further
>>> issues. But fixing this properly would be much preferred.
>>>
>>> David Miller is still maintainer of the ESP code - I can't think of
>>> anyone better suited to answer ESP specific questions really.
>>>
>>> Cheers,
>>>
>>>     Michael
>>>
>> I got it to work. Somehow, at least. I wrote the driver to use PIO for
>> command block reads and writes, and found out that it didn't fix the
> Thanks, that does indeed absolve DMA.
>
>> problem. Using PIO, only the first byte of the tag message comes through. It
>> might not be esp_scsi's fault, but there seems to be an assumption that all
>> devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip
>> by esp_scsi.
> I'd have to check with DaveM, but such an assumption might in fact exist.
>
> SCSI-2 features might have been disabled in response to your disk's
> response in the device configure phase. Maybe someone with a newer
In fact, the features are never enabled under any circumstance. But, 
they only seem to add some functionality in how queue tag messages are 
processed by the chip and not necessarily forbid the functionality if 
not used.
> SCSI disk (one that does support TCQ from scratch, and the full SCSI-2
> command set or better) should try the original driver sometime.
>
> What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
> higher? (Apologies for asking this - it will be in one of your old
> logs but I cannot easily read these here.)
>
The drive you would find by searching with the model number in the logs 
would point you to an IDE drive, which is actually connected to a bridge 
adapter (ACard AEC-7720U) that supports full Ultra SCSI features. I also 
have a 'real' ST51080N that supports Fast SCSI-2 that I've also tested 
with the driver to no avail. I will double check again with the real 
SCSI drive to ascertain that the bridge adapter is not the culprit, just 
to make sure.

-Tuomas

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Geert Uytterhoeven]

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

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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

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

On 09/11/2013 04:08 PM, Tuomas Vainikka wrote:
> On 09/11/2013 01:12 PM, Michael Schmitz wrote:
>> Hello Tuomas,
>>
>>>> That's the attitude - my suggestion was purely pragmatic, in order to
>>>> overcome that particular roadblock and see whether there's further
>>>> issues. But fixing this properly would be much preferred.
>>>>
>>>> David Miller is still maintainer of the ESP code - I can't think of
>>>> anyone better suited to answer ESP specific questions really.
>>>>
>>>> Cheers,
>>>>
>>>>     Michael
>>>>
>>> I got it to work. Somehow, at least. I wrote the driver to use PIO for
>>> command block reads and writes, and found out that it didn't fix the
>> Thanks, that does indeed absolve DMA.
>>
>>> problem. Using PIO, only the first byte of the tag message comes 
>>> through. It
>>> might not be esp_scsi's fault, but there seems to be an assumption 
>>> that all
>>> devices support TCQ. Also, no SCSI-2 features seem to be enabled in 
>>> the chip
>>> by esp_scsi.
>> I'd have to check with DaveM, but such an assumption might in fact 
>> exist.
>>
>> SCSI-2 features might have been disabled in response to your disk's
>> response in the device configure phase. Maybe someone with a newer
> In fact, the features are never enabled under any circumstance. But, 
> they only seem to add some functionality in how queue tag messages are 
> processed by the chip and not necessarily forbid the functionality if 
> not used.
>> SCSI disk (one that does support TCQ from scratch, and the full SCSI-2
>> command set or better) should try the original driver sometime.
>>
>> What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
>> higher? (Apologies for asking this - it will be in one of your old
>> logs but I cannot easily read these here.)
>>
> The drive you would find by searching with the model number in the 
> logs would point you to an IDE drive, which is actually connected to a 
> bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI 
> features. I also have a 'real' ST51080N that supports Fast SCSI-2 that 
> I've also tested with the driver to no avail. I will double check 
> again with the real SCSI drive to ascertain that the bridge adapter is 
> not the culprit, just to make sure.
>
The driver without the slave_configure hack fails with the same IRQ2 
timeout when the ST51080N hdd is used (see zesp164_orig_slave_cfg.cap).
When the hack is enabled, the hdd works like a charm; none of the 
aforementioned messages (wrong page, write again) are produced (and the 
speed is nearly acceptable :-) ) (see zesp165_hacked_slave_cfg.cap).

-Tuomas

[-- Attachment #2: zesp164_orig_slave_cfg.cap.gz --]
[-- Type: application/x-gzip, Size: 4905 bytes --]

[-- Attachment #3: zesp165_hacked_slave_cfg.cap.gz --]
[-- Type: application/x-gzip, Size: 1726 bytes --]

esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)

[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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Hello Tuomas,

apologies for dropping off the conversation for so long - I only 
returned from an overseas trip with only sporadic net access three days 
ago.

>> What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
>> higher? (Apologies for asking this - it will be in one of your old
>> logs but I cannot easily read these here.)
>>
> The drive you would find by searching with the model number in the 
> logs would point you to an IDE drive, which is actually connected to a 
> bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI 
> features. I also have a 'real' ST51080N that supports Fast SCSI-2 that 
> I've also tested with the driver to no avail. I will double check 
> again with the real SCSI drive to ascertain that the bridge adapter is 
> not the culprit, just to make sure.

I'm fully aware the info would have been in the logs, but all I had to 
work with was a dodgy XP box at my in-law's place, and not a lot of 
time to poke around.

You have established that the SCSI bridge is responsible for a few odd 
warnings but nothing serious, so I'd say we give your patched driver a 
good workout on a number of Amiga m68k porter boxes, Unless you beat me 
to it, I would suggest I provide a patch against Geert's latest m68k 
development tree for someone else to integrate into the Debian kernel 
package (would be a highly experimental one). Does that sound fair?

Cheers,

   Michael

Re: esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)

[Michael Schmitz]

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

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Tuomas Vainikka]

On 09/26/2013 04:44 PM, Michael Schmitz wrote:
> Hello Tuomas,
>
> apologies for dropping off the conversation for so long - I only 
> returned from an overseas trip with only sporadic net access three 
> days ago.
>
>>> What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
>>> higher? (Apologies for asking this - it will be in one of your old
>>> logs but I cannot easily read these here.)
>>>
>> The drive you would find by searching with the model number in the 
>> logs would point you to an IDE drive, which is actually connected to 
>> a bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI 
>> features. I also have a 'real' ST51080N that supports Fast SCSI-2 
>> that I've also tested with the driver to no avail. I will double 
>> check again with the real SCSI drive to ascertain that the bridge 
>> adapter is not the culprit, just to make sure.
>
> I'm fully aware the info would have been in the logs, but all I had to 
> work with was a dodgy XP box at my in-law's place, and not a lot of 
> time to poke around.
>
> You have established that the SCSI bridge is responsible for a few odd 
> warnings but nothing serious, so I'd say we give your patched driver a 
> good workout on a number of Amiga m68k porter boxes, Unless you beat 
> me to it, I would suggest I provide a patch against Geert's latest 
> m68k development tree for someone else to integrate into the Debian 
> kernel package (would be a highly experimental one). Does that sound 
> fair?
>
Go ahead. I assume you can now open the attachments? If you could just 
make one small modification; all controllers but Oktagon use a 40 MHz 
clock. The zorro_esp driver versions I've been spamming to this list all 
have carried a bad 20 MHz clock setting for the Blizzard 2060 board.

I've actually been able to compile the driver into the kernel and use it 
for root fs (on my Blizzard 1230-IV).

-Tuomas

Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver

[Michael Schmitz]

Hello Tuomas,

>>

> Go ahead. I assume you can now open the attachments? If you could just 
> make one small modification; all controllers

You bet - though sz compressed .deb packages would still defeat me :-) 
 From here on it's just roadblocks like git rebase as usual.

By rightrs someone with access to the actual hardware should maintain 
the driver in the long term though.

> but Oktagon use a 40 MHz clock. The zorro_esp driver versions I've 
> been spamming to this list all have carried a bad 20 MHz clock setting 
> for the Blizzard 2060 board.

I'll do that, sure.

> I've actually been able to compile the driver into the kernel and use 
> it for root fs (on my Blizzard 1230-IV).

That should count for a successful acid test. Thanks so much for 
completing and debugging my rather rough draft!

Cheers,

	Michael

Re: esp_scsi QTAG in FAS216

[David Miller]

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.

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

[David Miller]

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.

Re: esp_scsi QTAG in FAS216

[Kars de Jong]

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.

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

[Kars de Jong]

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.

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

[David Miller]

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);
 		}
 	}
 }

Re: esp_scsi QTAG in FAS216

[Tuomas Vainikka]

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

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

[-- 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 --]

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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);
>  		}
>  	}
>  }

Re: esp_scsi QTAG in FAS216

[Tuomas Vainikka]

[-- 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 --]

Re: esp_scsi QTAG in FAS216

[Geert Uytterhoeven]

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

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

[Finn Thain]

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);
>  		}
>  	}
>  }

Re: esp_scsi QTAG in FAS216

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

-- 

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

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

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

Re: esp_scsi QTAG in FAS216

[Michael Schmitz]

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

Re: esp_scsi QTAG in FAS216

[Finn Thain]

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
>