Skip to contentSkip to conversation

Experimental Amiga Zorro ESP driver

PATCH In review Michael Schmitz 6 participants 53 messages Jun 6, 2013 – Nov 1, 2016 SCSI

lore
Share & tools
lore
#0 lore raw

cover Experimental Amiga Zorro ESP driver

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

#1 lore raw

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

---
 drivers/scsi/Kconfig  |   16 ++++++++++++++++
 drivers/scsi/Makefile |    1 +
 2 files changed, 17 insertions(+), 0 deletions(-)
drivers/scsi/Kconfig +16 -0
index db95c54..8a08ee6 100644
@@ -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
drivers/scsi/Makefile +1 -0
index b607ba4..487b8c5 100644
@@ -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
Signature · 1 line
1.7.0.4
#2 lore raw

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

In reply to Michael Schmitz
---
 drivers/scsi/zorro_esp.c |  414 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 414 insertions(+), 0 deletions(-)
 create mode 100644 drivers/scsi/zorro_esp.c
drivers/scsi/zorro_esp.c new file +414 -0
new file mode 100644
index 0000000..b0d4a56
@@ -0,0 +1,414 @@
+/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
+ *
+ * Copyright (C) 1996 Jesper Skov ([email protected])
+ *
+ * Copyright (C) 2011 Michael Schmitz ([email protected]) 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 <[email protected]>
+ * plus modifications of the 53c7xx.c driver to support the Amiga.
+ *
+ * Rewritten to use 53c700.c by Kars de Jong <[email protected]>
+ */
+
+#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 <[email protected]>");
+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);
Signature · 1 line
1.7.0.4
#3 lore raw
In reply to Michael Schmitz
Quoted 7 lines · 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.

Quoted 5 lines

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

#4 lore raw
Quoted 15 lines · Tuomas Vainikka
Quoted 7 lines · 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.

Quoted 5 lines

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.

Quoted 8 lines

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

#5 lore raw

HelloTuomas,

Quoted 14 lines · Tuomas Vainikka
Quoted 13 lines · Michael Schmitz
Quoted 12 lines

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.

Quoted 4 lines
Quoted 4 lines

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!

Quoted 6 lines
Quoted 6 lines

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.

Quoted 12 lines

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

Quoted 8 lines
[  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

Quoted 3 lines

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

#6 lore raw
Quoted 4 lines · Michael Schmitz
Quoted 2 lines
[  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

#7 lore raw

Tuomas,

Quoted 20 lines
Quoted 4 lines
Quoted 2 lines
[  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
Quoted 1 line

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.

Quoted 1 line

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

#8 lore raw
Quoted 1 line · Michael Schmitz
Quoted 1 line
Quoted 1 line
Quoted 1 line
[  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...

Quoted 23 lines
Quoted 19 lines
Quoted 3 lines

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
Quoted 2 lines

Seems like IRQ2 is very popular, so it's hard to say which device has generated the interrupts...

Quoted 6 lines

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

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

#9 lore raw

Geert,

Quoted 14 lines · Michael Schmitz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
  
[  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;
        }
Quoted 4 lines

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?

Quoted 28 lines
Quoted 28 lines
Quoted 20 lines
Quoted 5 lines

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
Quoted 3 lines

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.

Quoted 5 lines
Quoted 2 lines

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.

Quoted 3 lines

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

#10 lore raw
Quoted 2 lines · Michael Schmitz

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

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

#11 lore raw

Geert,

Quoted 8 lines · Michael Schmitz
Quoted 4 lines

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

#12 lore raw
Quoted 5 lines · Michael Schmitz

Geert,

Quoted 4 lines · Michael Schmitz
Quoted 2 lines

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

Quoted 9 lines
Quoted 1 line

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

#13 lore raw
Quoted 1 line · Tuomas Vainikka

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

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

#14 lore raw
In reply to Michael Schmitz
Quoted 10 lines · Michael Schmitz

Geert,

Quoted 5 lines · Michael Schmitz
Quoted 2 lines

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

Quoted 8 lines

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

#15 lore raw

Tuomas,

Quoted 1 line

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-

Quoted 2 lines

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

Quoted 29 lines

...

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

#16 lore raw
Quoted 7 lines · Michael Schmitz

Tuomas,

Quoted 1 line

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

Quoted 7 lines
Quoted 3 lines

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.

Quoted 3 lines

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

#17 lore raw

Hello Tuomas,

Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 9 lines
Quoted 5 lines

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

Quoted 53 lines · Tuomas Vainikka
Quoted 11 lines · Michael Schmitz

Tuomas,

Quoted 6 lines

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.

Quoted 7 lines

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

Quoted 10 lines
Quoted 5 lines

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.

Quoted 6 lines

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

#18 lore raw
Quoted 31 lines · Michael Schmitz

Hello Tuomas,

Quoted 4 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 9 lines
Quoted 5 lines

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.

Quoted 8 lines

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

#19 lore raw
In reply to Michael Schmitz
Quoted 35 lines · Michael Schmitz

Hello Tuomas,

Quoted 4 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 9 lines
Quoted 5 lines

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.

Quoted 7 lines

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

#20 lore raw

Hello Tuomas,

Quoted 7 lines
Quoted 7 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 4 lines

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

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 1 line

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

Quoted 79 lines · Tuomas Vainikka
Quoted 45 lines · Michael Schmitz

Hello Tuomas,

Quoted 5 lines
Quoted 3 lines

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.

Quoted 8 lines

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.

Quoted 7 lines
Quoted 7 lines

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

Quoted 6 lines

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.

Quoted 7 lines

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

#21 lore raw
Quoted 17 lines · Michael Schmitz

Hello Tuomas,

Quoted 7 lines
Quoted 7 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 7 lines

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

#22 lore raw
Quoted 27 lines · Tuomas Vainikka
Quoted 17 lines · Michael Schmitz

Hello Tuomas,

Quoted 7 lines
Quoted 7 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 9 lines
Quoted 7 lines

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

#23 lore raw
In reply to Tuomas Vainikka

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.

Quoted 5 lines
Quoted 4 lines

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

#24 lore raw
Quoted 8 lines · 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.

Quoted 4 lines
Quoted 4 lines

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

Quoted 6 lines
Quoted 1 line

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

#25 lore raw

Hello Tuomas,

Quoted 3 lines
Quoted 1 line

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.

Quoted 1 line

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.

Quoted 1 line

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

#26 lore raw
In reply to Michael Schmitz
Quoted 6 lines · Michael Schmitz
Quoted 4 lines

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 [email protected] and David S. Miller <[email protected]> on future discussions.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

#27 lore raw

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

Quoted 5 lines · Geert Uytterhoeven
Quoted 4 lines · Michael Schmitz
Quoted 4 lines

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.

Quoted 9 lines
Quoted 1 line

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

BTW, it would be nice to start CCing [email protected] and David S. Miller <[email protected]> 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

#28 lore raw

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

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:

Quoted 24 lines · Geert Uytterhoeven
Quoted 5 lines · Michael Schmitz
Quoted 4 lines
Quoted 4 lines

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.

Quoted 9 lines
Quoted 1 line

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

BTW, it would be nice to start CCing [email protected] and David S. Miller <[email protected]> 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

#29 lore raw

Re: esp_scsi QTAG in FAS216

In reply to Tuomas Vainikka

From: Tuomas Vainikka <[email protected]>
Date: Thu, 12 Sep 2013 18:36:09 +0300

Quoted 4 lines

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.

Quoted 3 lines

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.

#30 lore raw

Re: esp_scsi QTAG in FAS216

Hello Dave, Tuomas,

Quoted 8 lines
Quoted 3 lines

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

#31 lore raw

Re: esp_scsi QTAG in FAS216

From: Michael Schmitz <[email protected]>
Date: Mon, 7 Apr 2014 08:33:12 +1200

Quoted 11 lines

Hello Dave, Tuomas,

Quoted 8 lines
Quoted 3 lines

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.

Quoted 5 lines

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.

#32 lore raw

Re: esp_scsi QTAG in FAS216

In reply to Michael Schmitz

2014-04-06 22:33 GMT+02:00 Michael Schmitz <[email protected]>:

Quoted 12 lines

Hello Dave, Tuomas,

Quoted 8 lines
Quoted 3 lines

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.

Quoted 5 lines

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.

#33 lore raw

Re: esp_scsi QTAG in FAS216

Hello Kars,

Quoted 14 lines
Quoted 10 lines
Quoted 4 lines

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

Quoted 6 lines

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

#34 lore raw

Re: esp_scsi QTAG in FAS216

Hi Michael,

2014-04-11 3:47 GMT+02:00 Michael Schmitz <[email protected]>:

Quoted 3 lines

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.

Quoted 1 line

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.

#35 lore raw

Re: esp_scsi QTAG in FAS216

Hi Kars,

thanks for the PDFs!

Quoted 7 lines

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.

Quoted 11 lines

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?

drivers/scsi/zorro_esp.c +4 -3
index 1a1eb95..b33c3b5 100644
@@ -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;
Quoted 10 lines

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

#36 lore raw

Re: esp_scsi QTAG in FAS216

From: Michael Schmitz <[email protected]>
Date: Mon, 14 Apr 2014 10:38:09 +1200

Quoted 10 lines

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?

...

Quoted 5 lines
Quoted 5 lines

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

And about the QTE bit:

Quoted 8 lines
Quoted 5 lines

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.

drivers/scsi/esp_scsi.c +1 -3
index 55548dc..16f69e0 100644
@@ -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);
 		}
 	}
 }
#37 lore raw

Re: esp_scsi QTAG in FAS216

Quoted 76 lines · David Miller

From: Michael Schmitz <[email protected]>
Date: Mon, 14 Apr 2014 10:38:09 +1200

Quoted 10 lines

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?

...

Quoted 5 lines
Quoted 5 lines

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

And about the QTE bit:

Quoted 7 lines
Quoted 5 lines

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.

drivers/scsi/esp_scsi.c +1 -1
index 55548dc..16f69e0 100644
@@ -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);

drivers/scsi/esp_scsi.c static void esp_get_revision(struct esp *esp) · line 2192

Quoted 8 lines
drivers/scsi/esp_scsi.c +0 -2
@@ -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

#38 lore raw

Re: esp_scsi QTAG in FAS216

Hi Tuomas,

Quoted 64 lines
Quoted 53 lines
Quoted 2 lines

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.

drivers/scsi/esp_scsi.c +1 -1
index 55548dc..16f69e0 100644
@@ -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);

drivers/scsi/esp_scsi.c static void esp_get_revision(struct esp *esp) · line 2192

Quoted 8 lines
drivers/scsi/esp_scsi.c +0 -2
@@ -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.

Quoted 2 lines

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

/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
*
* Copyright (C) 1996 Jesper Skov ([email protected])
*
* Copyright (C) 2011 Michael Schmitz ([email protected]) 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 <[email protected]>
* plus modifications of the 53c7xx.c driver to support the Amiga. *
* Rewritten to use 53c700.c by Kars de Jong <[email protected]> */

#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 <[email protected]>"); 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);

#39 lore raw

Re: esp_scsi QTAG in FAS216

Hi Michael,

[sorry for the long delay]

Quoted 4 lines · Michael Schmitz

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

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

#40 lore raw

Re: esp_scsi QTAG in FAS216

Hi Geert,

Quoted 1 line

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

Quoted 8 lines · Michael Schmitz
Quoted 4 lines

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

#41 lore raw

Re: esp_scsi QTAG in FAS216

In reply to David Miller

Hi Dave,

Quoted 11 lines
Quoted 6 lines
Quoted 3 lines

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.

Quoted 9 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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

Quoted 33 lines

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

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

drivers/scsi/esp_scsi.c +1 -3
index 55548dc..16f69e0 100644
@@ -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);
 		}
 	}
 }
#42 lore raw

Re: esp_scsi QTAG in FAS216

Quoted 72 lines · Michael Schmitz

Hi Dave,

Quoted 11 lines
Quoted 6 lines
Quoted 3 lines

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.

Quoted 9 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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

Quoted 25 lines

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

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

drivers/scsi/esp_scsi.c +1 -1
index 55548dc..16f69e0 100644
@@ -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)
Quoted 9 lines

drivers/scsi/esp_scsi.c static void esp_get_revision(struct esp *esp) · line 2192

Quoted 8 lines
drivers/scsi/esp_scsi.c +0 -2
             } 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

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:~# 
#43 lore raw

Re: esp_scsi QTAG in FAS216

In reply to David Miller
Quoted 19 lines · David Miller
Quoted 4 lines

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?

...

Quoted 5 lines
Quoted 5 lines

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

And about the QTE bit:

Quoted 8 lines
Quoted 5 lines

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?

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

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?

Quoted 5 lines

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.

Quoted 33 lines

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

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

drivers/scsi/esp_scsi.c +1 -3
index 55548dc..16f69e0 100644
@@ -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);
 		}
 	}
 }
#44 lore raw

Re: esp_scsi QTAG in FAS216

Quoted 8 lines · On Sat, 29 Oct 2016, I wrote:
Quoted 5 lines · David Miller

But oddly in the NCR53CX docs:

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

Quoted 8 lines
Quoted 3 lines

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

#45 lore raw

Re: esp_scsi QTAG in FAS216

Hi Finn,

Am 30.10.2016 um 15:33 schrieb Finn Thain:

Quoted 20 lines · On Sat, 29 Oct 2016, I wrote:
Quoted 9 lines · David Miller
Quoted 6 lines

But oddly in the NCR53CX docs:

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

Quoted 8 lines
Quoted 3 lines

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?

Quoted 6 lines

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

#46 lore raw

Re: esp_scsi QTAG in FAS216

Hi Finn,

Quoted 3 lines

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

#47 lore raw

Re: esp_scsi QTAG in FAS216

Quoted 7 lines · Michael Schmitz
Quoted 3 lines

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.

Quoted 6 lines

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

Cheers,

Michael

#48 lore raw

Re: esp_scsi QTAG in FAS216

Hi Finn,

Am 01.11.2016 um 12:47 schrieb Finn Thain:

Quoted 7 lines · Michael Schmitz
Quoted 5 lines
Quoted 4 lines

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

Quoted 6 lines
Quoted 3 lines

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?

Quoted 3 lines

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

#49 lore raw

Re: esp_scsi QTAG in FAS216

Quoted 14 lines · Michael Schmitz

Hi Finn,

Am 01.11.2016 um 12:47 schrieb Finn Thain:

Quoted 11 lines · Michael Schmitz
Quoted 8 lines
Quoted 4 lines

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?

Quoted 6 lines
Quoted 2 lines

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.

Quoted 19 lines
Quoted 5 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#50 lore raw
In reply to Michael Schmitz
Quoted 48 lines · Michael Schmitz

Geert,

Quoted 12 lines · Michael Schmitz
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[  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;
        }
Quoted 3 lines

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?

Quoted 27 lines
Quoted 26 lines
Quoted 18 lines
Quoted 3 lines

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
Quoted 2 lines

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.

Quoted 8 lines
Quoted 1 line

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.

Quoted 2 lines

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

#51 lore raw
Quoted 4 lines · Tuomas Vainikka

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.

Quoted 3 lines

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

Quoted 2 lines

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

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

#52 lore raw
Quoted 6 lines · Geert Uytterhoeven
Quoted 4 lines · Tuomas Vainikka

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

Quoted 7 lines

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