Discussion:
[PATCH 0/2] Experimental Amiga Zorro ESP driver
Michael Schmitz
2013-06-06 20:56:37 UTC
Permalink
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
Michael Schmitz
2013-06-06 20:56:38 UTC
Permalink
---
drivers/scsi/Kconfig | 16 ++++++++++++++++
drivers/scsi/Makefile | 1 +
2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index db95c54..8a08ee6 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1644,6 +1644,22 @@ config SCSI_ZORRO7XX
accelerator card for the Amiga 1200,
- the SCSI controller on the GVP Turbo 040/060 accelerator.

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

diff --git a/drivers/scsi/zorro_esp.c b/drivers/scsi/zorro_esp.c
new file mode 100644
index 0000000..b0d4a56
--- /dev/null
+++ b/drivers/scsi/zorro_esp.c
@@ -0,0 +1,414 @@
+/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
+ *
+ * Copyright (C) 1996 Jesper Skov (***@cygnus.co.uk)
+ *
+ * Copyright (C) 2011 Michael Schmitz (***@debian.org) for
+ * migration to ESP SCSI core
+ */
+/*
+ * ZORRO bus code from:
+ */
+/*
+ * Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux.
+ * Amiga MacroSystemUS WarpEngine SCSI controller.
+ * Amiga Technologies/DKB A4091 SCSI controller.
+ *
+ * Written 1997 by Alan Hourihane <***@fairlite.demon.co.uk>
+ * plus modifications of the 53c7xx.c driver to support the Amiga.
+ *
+ * Rewritten to use 53c700.c by Kars de Jong <***@linux-m68k.org>
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/dma-mapping.h>
+#include <linux/scatterlist.h>
+#include <linux/zorro.h>
+#include <linux/slab.h>
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <asm/cacheflush.h>
+#include <asm/amigahw.h>
+#include <asm/amigaints.h>
+
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_transport_spi.h>
+
+#include "esp_scsi.h"
+
+MODULE_AUTHOR("Michael Schmitz <***@debian.org>");
+MODULE_DESCRIPTION("Amiga Zorro NCR5C9x (ESP) driver");
+MODULE_LICENSE("GPL");
+
+
+static struct scsi_host_template zorro_esp_scsi_driver_template = {
+ .proc_name = "zorro-esp",
+ .this_id = 7,
+ .module = THIS_MODULE,
+};
+
+static struct zorro_driver_data {
+ const char *name;
+ unsigned long offset;
+ unsigned long dma_offset;
+ int absolute;
+ int zorro3; /* offset is absolute address */
+} zorro_esp_driver_data[] = {
+ { .name = "CyberStormI", .offset = 0xf400, .dma_offset = 0xf800 },
+ { .name = "CyberStormII", .offset = 0x1ff03, .dma_offset = 0x1ff43 },
+ { .name = "Blizzard 2060", .offset = 0x1ff00, .dma_offset = 0x1ffe0 },
+ { .name = "Blizzard 1230", .offset = 0x8000, .dma_offset = 0x10000 },
+ { .name = "Blizzard 1230II", .offset = 0x10000, .dma_offset = 0x10021 },
+ { .name = "Fastlane", .offset = 0x1000001, .dma_offset = 0x1000041, .zorro3 = 1 },
+ { 0 }
+};
+
+static struct zorro_device_id zorro_esp_zorro_tbl[] = {
+ {
+ .id = ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM,
+ .driver_data = (unsigned long)&zorro_esp_driver_data[0],
+ },
+ {
+ .id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
+ .driver_data = (unsigned long)&zorro_esp_driver_data[0],
+ },
+ {
+ .id = ZORRO_PROD_PHASE5_CYBERSTORM_MK_II,
+ .driver_data = (unsigned long)&zorro_esp_driver_data[1],
+ },
+ {
+ .id = ZORRO_PROD_PHASE5_BLIZZARD_2060,
+ .driver_data = (unsigned long)&zorro_esp_driver_data[2],
+ },
+ {
+ .id = ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260,
+ .driver_data = (unsigned long)&zorro_esp_driver_data[3],
+ },
+ {
+ .id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
+ .driver_data = (unsigned long)&zorro_esp_driver_data[4],
+ },
+ { 0 }
+};
+MODULE_DEVICE_TABLE(zorro, zorro_esp_zorro_tbl);
+
+/* The controller registers can be found in the Z2 config area at these
+ * offsets:
+ */
+#define BLZ2060_ESP_ADDR 0x1ff00
+#define BLZ2060_DMA_ADDR 0x1ffe0
+
+
+/* The Blizzard 2060 DMA interface
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * Only two things can be programmed in the Blizzard DMA:
+ * 1) The data direction is controlled by the status of bit 31 (1 = write)
+ * 2) The source/dest address (word aligned, shifted one right) in bits 30-0
+ *
+ * Figure out interrupt status by reading the ESP status byte.
+ */
+struct blz2060_dma_registers {
+ volatile unsigned char dma_led_ctrl; /* DMA led control [0x000] */
+ unsigned char dmapad1[0x0f];
+ volatile unsigned char dma_addr0; /* DMA address (MSB) [0x010] */
+ unsigned char dmapad2[0x03];
+ volatile unsigned char dma_addr1; /* DMA address [0x014] */
+ unsigned char dmapad3[0x03];
+ volatile unsigned char dma_addr2; /* DMA address [0x018] */
+ unsigned char dmapad4[0x03];
+ volatile unsigned char dma_addr3; /* DMA address (LSB) [0x01c] */
+};
+
+#define BLZ2060_DMA_WRITE 0x80000000
+
+/* DMA control bits */
+#define BLZ2060_DMA_LED 0x02 /* HD led control 1 = off */
+
+
+/*
+ * m68k always assumes readl/writel operate on little endian
+ * mmio space; this is wrong at least for Sun3x, so we
+ * need to workaround this until a proper way is found
+ */
+#if 0
+#define dma_read32(REG) \
+ readl(esp->dma_regs + (REG))
+#define dma_write32(VAL, REG) \
+ writel((VAL), esp->dma_regs + (REG))
+#else
+#define dma_read32(REG) \
+ *(volatile u32 *)(esp->dma_regs + (REG))
+#define dma_write32(VAL, REG) \
+ do { *(volatile u32 *)(esp->dma_regs + (REG)) = (VAL); } while (0)
+#endif
+
+/*
+ * On all implementations except for the Oktagon, padding between ESP
+ * registers is three bytes.
+ * On Oktagon, it is one byte - use a different accessor there.
+ *
+ * Oktagon currently unsupported!
+ */
+
+static void zorro_esp_write8(struct esp *esp, u8 val, unsigned long reg)
+{
+ writeb(val, esp->regs + (reg * 4UL));
+}
+
+static u8 zorro_esp_read8(struct esp *esp, unsigned long reg)
+{
+ return readb(esp->regs + (reg * 4UL));
+}
+
+static dma_addr_t zorro_esp_map_single(struct esp *esp, void *buf,
+ size_t sz, int dir)
+{
+ return dma_map_single(esp->dev, buf, sz, dir);
+}
+
+static int zorro_esp_map_sg(struct esp *esp, struct scatterlist *sg,
+ int num_sg, int dir)
+{
+ return dma_map_sg(esp->dev, sg, num_sg, dir);
+}
+
+static void zorro_esp_unmap_single(struct esp *esp, dma_addr_t addr,
+ size_t sz, int dir)
+{
+ dma_unmap_single(esp->dev, addr, sz, dir);
+}
+
+static void zorro_esp_unmap_sg(struct esp *esp, struct scatterlist *sg,
+ int num_sg, int dir)
+{
+ dma_unmap_sg(esp->dev, sg, num_sg, dir);
+}
+
+static int zorro_esp_irq_pending(struct esp *esp)
+{
+ /* check ESP status register; DMA has no status reg. */
+ if (zorro_esp_read8(esp, ESP_STATUS) & ESP_STAT_INTR)
+ return 1;
+
+ return 0;
+}
+
+static void zorro_esp_reset_dma(struct esp *esp)
+{
+ /* nothing to do here */
+}
+
+static void zorro_esp_dma_drain(struct esp *esp)
+{
+ /* nothing to do here */
+}
+
+static void zorro_esp_dma_invalidate(struct esp *esp)
+{
+ /* nothing to do here */
+}
+
+static void zorro_esp_send_dma_cmd(struct esp *esp, u32 addr, u32 esp_count,
+ u32 dma_count, int write, u8 cmd)
+{
+ struct blz2060_dma_registers *dregs =
+ (struct blz2060_dma_registers *) (esp->dma_regs);
+
+ BUG_ON(!(cmd & ESP_CMD_DMA));
+ zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
+ zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
+
+ /*
+ * This will differ among Amiga ESP implementations - DMA setup!
+ */
+
+ if (write)
+ cache_clear(addr, esp_count);
+ else
+ cache_push(addr, esp_count);
+
+ /* On the Sparc, DMA_ST_WRITE means "move data from device to memory"
+ * so when (write) is true, it actually means READ (from the ESP)!
+ */
+ addr >>= 1;
+ if (write)
+ addr &= ~(BLZ2060_DMA_WRITE);
+ else
+ addr |= BLZ2060_DMA_WRITE;
+
+ dregs->dma_addr3 = (addr ) & 0xff;
+ dregs->dma_addr2 = (addr >> 8) & 0xff;
+ dregs->dma_addr1 = (addr >> 16) & 0xff;
+ dregs->dma_addr0 = (addr >> 24) & 0xff;
+
+ scsi_esp_cmd(esp, cmd);
+}
+
+static int zorro_esp_dma_error(struct esp *esp)
+{
+ /* nothing to do here - there seems to be no way to check for DMA errors */
+ return 0;
+}
+
+static const struct esp_driver_ops zorro_esp_ops = {
+ .esp_write8 = zorro_esp_write8,
+ .esp_read8 = zorro_esp_read8,
+ .map_single = zorro_esp_map_single,
+ .map_sg = zorro_esp_map_sg,
+ .unmap_single = zorro_esp_unmap_single,
+ .unmap_sg = zorro_esp_unmap_sg,
+ .irq_pending = zorro_esp_irq_pending,
+ .reset_dma = zorro_esp_reset_dma,
+ .dma_drain = zorro_esp_dma_drain,
+ .dma_invalidate = zorro_esp_dma_invalidate,
+ .send_dma_cmd = zorro_esp_send_dma_cmd,
+ .dma_error = zorro_esp_dma_error,
+};
+
+static int zorro_esp_init_one(struct zorro_dev *z,
+ const struct zorro_device_id *ent)
+{
+ struct scsi_host_template *tpnt = &zorro_esp_scsi_driver_template;
+ struct Scsi_Host *host;
+ struct esp *esp;
+ struct zorro_driver_data *zdd;
+ unsigned long board, ioaddr, dmaaddr, esp_base;
+ int err = -ENOMEM;
+
+ board = zorro_resource_start(z);
+ zdd = (struct zorro_driver_data *)ent->driver_data;
+
+ if (zdd->absolute) {
+ ioaddr = zdd->offset;
+ dmaaddr = zdd->dma_offset;
+ } else {
+ ioaddr = board + zdd->offset;
+ dmaaddr = board + zdd->dma_offset;
+ }
+
+ if (!zorro_request_device(z, zdd->name)) {
+ printk(KERN_ERR "zorro_esp: cannot reserve region 0x%lx, abort\n",
+ board);
+ return -EBUSY;
+ }
+
+ /* Fill in the required pieces of hostdata */
+ if (ioaddr > 0x01000000)
+ esp_base = ioremap(ioaddr, zorro_resource_len(z));
+ else
+ esp_base = (void __iomem *)ZTWO_VADDR(ioaddr);
+
+ zorro_esp_scsi_driver_template.name = zdd->name;
+
+ /* and register the chip */
+ host = scsi_host_alloc(tpnt, sizeof(struct esp));
+
+ if (!host) {
+ printk(KERN_ERR "zorro_esp: No host detected; "
+ "board configuration problem?\n");
+ goto out_free;
+ }
+
+ host->max_id = 8;
+ esp = shost_priv(host);
+
+ esp->host = host;
+ esp->dev = z;
+ esp->ops = &zorro_esp_ops;
+
+ esp->regs = ioremap_nocache(ioaddr, 0x20);
+ if (!esp->regs)
+ goto fail_unmap_regs;
+
+ esp->dma_regs = ioremap_nocache(dmaaddr, 0x20);
+
+ esp->command_block = dma_alloc_coherent(esp->dev, 32,
+ &esp->command_block_dma,
+ GFP_KERNEL);
+ if (!esp->command_block)
+ goto fail_unmap_regs_dma;
+
+ host->irq = IRQ_AMIGA_PORTS;
+ err = request_irq(host->irq, scsi_esp_intr, IRQF_SHARED,
+ "Amiga Zorro ESP", esp);
+ if (err < 0)
+ goto fail_unmap_command_block;
+
+ esp->scsi_id = 7;
+ esp->host->this_id = esp->scsi_id;
+ esp->scsi_id_mask = (1 << esp->scsi_id);
+ esp->cfreq = 20000000;
+
+ dev_set_drvdata(&z->dev, esp);
+
+ err = scsi_esp_register(esp, &z->dev);
+ if (err)
+ goto fail_free_irq;
+
+ zorro_set_drvdata(z, host);
+ scsi_scan_host(host);
+
+ return 0;
+
+fail_free_irq:
+ free_irq(host->irq, esp);
+fail_unmap_command_block:
+ dma_free_coherent(esp->dev, 16,
+ esp->command_block,
+ esp->command_block_dma);
+fail_unmap_regs_dma:
+ iounmap(esp->dma_regs);
+fail_unmap_regs:
+ iounmap(esp->regs);
+ scsi_host_put(host);
+out_free:
+ if (ioaddr > 0x01000000)
+ iounmap(esp_base);
+out_release:
+ zorro_release_device(z);
+
+ return -ENODEV;
+}
+
+static void zorro_esp_remove_one(struct zorro_dev *z)
+{
+ struct Scsi_Host *host = zorro_get_drvdata(z);
+ struct esp *esp = dev_get_drvdata(&z->dev);
+ unsigned int irq = esp->host->irq;
+ u32 val;
+
+ scsi_esp_unregister(esp);
+
+ /* Disable interrupts. Perhaps use disable_irq instead ... */
+
+ free_irq(irq, esp);
+ dma_free_coherent(esp->dev, 16,
+ esp->command_block,
+ esp->command_block_dma);
+
+ scsi_host_put(esp->host);
+
+ zorro_release_device(z);
+}
+
+static struct zorro_driver zorro_esp_driver = {
+ .name = "zorro_esp-scsi",
+ .id_table = zorro_esp_zorro_tbl,
+ .probe = zorro_esp_init_one,
+ .remove = zorro_esp_remove_one,
+};
+
+static int __init zorro_esp_scsi_init(void)
+{
+ return zorro_register_driver(&zorro_esp_driver);
+}
+
+static void __exit zorro_esp_scsi_exit(void)
+{
+ zorro_unregister_driver(&zorro_esp_driver);
+}
+
+module_init(zorro_esp_scsi_init);
+module_exit(zorro_esp_scsi_exit);
--
1.7.0.4
Tuomas Vainikka
2013-08-15 21:40:51 UTC
Permalink
Post by Michael Schmitz
Geert,
other than 'it compiles', I can't really say much about this one.
I've done what seemed necessary to do the ESP probe setup in the
zorro driver framework (using the NCR7xx driver as a guideline),
and used the old Blizzard 2060 driver as a model for the DMA setup.
To adapt to another style of ESP integration, the DMA setup function
will need to be changed. The simplest way to cater for multipe boards
in this driver may be to provide a separate DMA setup function for
each, and substitute the correct one for the default esp_ops field in
the driver probe. Please correct me if you see a better or simpler way.
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
Tuomas Vainikka
2013-08-16 19:01:16 UTC
Permalink
Post by Tuomas Vainikka
Post by Michael Schmitz
Geert,
other than 'it compiles', I can't really say much about this one.
I've done what seemed necessary to do the ESP probe setup in the
zorro driver framework (using the NCR7xx driver as a guideline),
and used the old Blizzard 2060 driver as a model for the DMA setup.
To adapt to another style of ESP integration, the DMA setup function
will need to be changed. The simplest way to cater for multipe boards
in this driver may be to provide a separate DMA setup function for
each, and substitute the correct one for the default esp_ops field in
the driver probe. Please correct me if you see a better or simpler way.
Thank you for rewriting the driver.
I copypasted the appropriate DMA code from blz1230.c, and added some
code to switch
to the appropriate function. I compiled the module, and was able to
insert and remove it.
The dmesg output is attached. I also attached the modified zorro_esp.c.
There is a HDD attached to the SCSI bus, but the scan does not take place.
The chip on the controller is a FAS216, but it is identified as a
FAS236. Does that matter?
I got a little further, but now there seems to be something wrong with
the IRQ:

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

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

-Tuomas
Michael Schmitz
2013-08-17 01:49:51 UTC
Permalink
HelloTuomas,
Post by Tuomas Vainikka
Post by Tuomas Vainikka
Post by Michael Schmitz
Geert,
other than 'it compiles', I can't really say much about this one.
I've done what seemed necessary to do the ESP probe setup in the
zorro driver framework (using the NCR7xx driver as a guideline),
and used the old Blizzard 2060 driver as a model for the DMA setup.
To adapt to another style of ESP integration, the DMA setup function
will need to be changed. The simplest way to cater for multipe boards
in this driver may be to provide a separate DMA setup function for
each, and substitute the correct one for the default esp_ops field in
the driver probe. Please correct me if you see a better or simpler way.
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!
Post by Tuomas Vainikka
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
I got a little further, but now there seems to be something wrong with
[ 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).
Post by Tuomas Vainikka
[ 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
Post by Tuomas Vainikka
-Tuomas
<zorro_esp.c.gz><zorro_esp_modprobe2.cap.gz>
Tuomas Vainikka
2013-08-17 11:33:21 UTC
Permalink
Post by Michael Schmitz
Post by Tuomas Vainikka
[ 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).
***@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
Michael Schmitz
2013-08-18 02:05:32 UTC
Permalink
Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
Post by Tuomas Vainikka
[ 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).
CPU0
2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP
6: 456970 auto CIAB
8: 38239 amiga serial TX
9: 0 amiga floppy_dma
12: 315934 amiga fb vertb handler
13: 315741 amiga serial status
15: 0 amiga DMA sound
19: 401 amiga serial RX
23: 1 cia floppy_timer
25: 0 cia amikbd
27: 456971 cia timer
ERR: 0
Seems like IRQ2 is very popular, so it's hard to say which device has
generated the interrupts...
Yep - you'll be guaranteed to get a few IDE interrupts just by calling
up cat - might be possible to get away without too much interrupts
generated if it's all in the buffer cache - try whether the interrupt
count changes after a few repetitions of that command.

Might require more elaborate IRQ bookkeeping though.
Post by Tuomas Vainikka
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
Geert Uytterhoeven
2013-08-18 08:23:15 UTC
Permalink
Post by Tuomas Vainikka
Post by Michael Schmitz
Post by Tuomas Vainikka
[ 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...
Post by Tuomas Vainikka
Post by Michael Schmitz
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).
CPU0
2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP
6: 456970 auto CIAB
8: 38239 amiga serial TX
9: 0 amiga floppy_dma
12: 315934 amiga fb vertb handler
13: 315741 amiga serial status
15: 0 amiga DMA sound
19: 401 amiga serial RX
23: 1 cia floppy_timer
25: 0 cia amikbd
27: 456971 cia timer
ERR: 0
Seems like IRQ2 is very popular, so it's hard to say which device has
generated the interrupts...
Yep - you'll be guaranteed to get a few IDE interrupts just by calling up
cat - might be possible to get away without too much interrupts generated if
it's all in the buffer cache - try whether the interrupt count changes after
a few repetitions of that command.
Might require more elaborate IRQ bookkeeping though.
I guess scsi_esp_intr() is called a lot, as it's a shared interrupt?
Can you add some debug prints there, to see if any of the conditions the
esp core checks are met?

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Michael Schmitz
2013-08-18 08:58:23 UTC
Permalink
Geert,
Post by Geert Uytterhoeven
Post by Tuomas Vainikka
Post by Michael Schmitz
Post by Tuomas Vainikka
[ 301.880000] esp: esp0: Reconnect IRQ2 timeout
Beware that this message (incl. the number) is hardcoded in
if (i == ESP_RESELECT_TAG_LIMIT) {
printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n",
esp->host->unique_id);
return NULL;
}
The driver prints "IRQ1" or "IRQ2".
Fortunately, IRQ_AMIGA_PORTS is 2, but this is purely coincidentally...
The driver attempts to DMA two bytes - can the DMA on the Zorro ESP
cards handle such short transfers?

I'll also need to check the command_block and command_block_dma
addresses - does the DMA require virtual or physical addresses?
Post by Geert Uytterhoeven
Post by Tuomas Vainikka
Post by Michael Schmitz
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).
CPU0
2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP
6: 456970 auto CIAB
8: 38239 amiga serial TX
9: 0 amiga floppy_dma
12: 315934 amiga fb vertb handler
13: 315741 amiga serial status
15: 0 amiga DMA sound
19: 401 amiga serial RX
23: 1 cia floppy_timer
25: 0 cia amikbd
27: 456971 cia timer
ERR: 0
Seems like IRQ2 is very popular, so it's hard to say which device has
generated the interrupts...
Yep - you'll be guaranteed to get a few IDE interrupts just by calling up
cat - might be possible to get away without too much interrupts generated if
it's all in the buffer cache - try whether the interrupt count changes after
a few repetitions of that command.
Might require more elaborate IRQ bookkeeping though.
I guess scsi_esp_intr() is called a lot, as it's a shared interrupt?
That's right - it will indeed be called a lot.
Post by Geert Uytterhoeven
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
Geert Uytterhoeven
2013-08-18 09:10:13 UTC
Permalink
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 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Michael Schmitz
2013-08-19 08:48:24 UTC
Permalink
Geert,
Post by Geert Uytterhoeven
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
Tuomas Vainikka
2013-08-19 11:47:15 UTC
Permalink
Post by Michael Schmitz
Geert,
On Sun, Aug 18, 2013 at 10:58 AM, 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.
:-) 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
Geert Uytterhoeven
2013-08-19 12:01:45 UTC
Permalink
On Mon, Aug 19, 2013 at 1:47 PM, Tuomas Vainikka
Post by 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 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Tuomas Vainikka
2013-08-19 20:46:02 UTC
Permalink
Post by Michael Schmitz
Geert,
On Sun, Aug 18, 2013 at 10:58 AM, 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.
:-) VDMA was invented a bit later ...
I'll go check the usage of the DMA API calls again, but as the driver
seems to do DMA fine until the short transfer, that seems the most
likely cause. PIO for dma_count < 7 might be an option.
I see transfers with esp_count=1 and dma_count=7 in the log - wonder
why that works but the short 2/2 byte case does not.
Cheers,
Michael
I guess those two bytes have something to do with target
(re)selection... There are two different ways of attempting to read
these bytes in the code, one is reading them from the FIFO byte by byte,
and the other way is to setup a DMA read (write from device). The two
different schemes are used in two different functions, and I do not
understand why one method would be preferred over the other when
comparing these functions.

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

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

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

-Tuomas
Michael Schmitz
2013-08-20 09:36:22 UTC
Permalink
Tuomas,
Post by Tuomas Vainikka
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-
Post by Tuomas Vainikka
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
Post by Tuomas Vainikka
...
[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>
Tuomas Vainikka
2013-08-20 10:00:40 UTC
Permalink
Post by Michael Schmitz
Tuomas,
Post by Tuomas Vainikka
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
Post by Michael Schmitz
Post by Tuomas Vainikka
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.
Post by Michael Schmitz
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
Michael Schmitz
2013-08-22 20:34:20 UTC
Permalink
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
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.
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
Post by Michael Schmitz
The DMA transfer function can be changed to fetch less than seven bytes
from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
after sending the command to the ESP, instead of first setting up the DMA
then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to
PIO. It is also possible that the chip interrupt is cleared prematurely by
reading the interrupt register, in which case the interrupt is not seen by
The Loop.
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.

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

Cheers,

Michael




On Tue, Aug 20, 2013 at 10:00 PM, Tuomas Vainikka
Post by Tuomas Vainikka
Post by Michael Schmitz
Tuomas,
I guess those two bytes have something to do with target (re)selection...
There are two different ways of attempting to read these bytes in the code,
one is reading them from the FIFO byte by byte, and the other way is to
setup a DMA read (write from device). The two different schemes are used in
two different functions, and I do not understand why one method would be
preferred over the other when comparing these functions.
What the driver attempts to read on reselection are the tag bytes that
were used in the previous disconnect. These have to match otherwise we are
not reselecting the command we need.
No idea which functions you refer to regarding PIO (reading from FIFO).
Anyway, the DMA will read from the same FIFO that the CPU would, if I
understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
Post by Michael Schmitz
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.
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.
Post by Michael Schmitz
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
Tuomas Vainikka
2013-08-31 10:37:44 UTC
Permalink
Post by Michael Schmitz
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
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.
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
Post by Michael Schmitz
The DMA transfer function can be changed to fetch less than seven bytes
from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
after sending the command to the ESP, instead of first setting up the DMA
then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to
PIO. It is also possible that the chip interrupt is cleared prematurely by
reading the interrupt register, in which case the interrupt is not seen by
The Loop.
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.
This might have nothing to do with the current issue, but during the
course of debugging this two byte dma write, I stumbled across this;

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

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

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

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

-Tuomas
Tuomas Vainikka
2013-09-10 21:13:11 UTC
Permalink
Post by Michael Schmitz
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
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.
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
Post by Michael Schmitz
The DMA transfer function can be changed to fetch less than seven bytes
from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
after sending the command to the ESP, instead of first setting up the DMA
then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to
PIO. It is also possible that the chip interrupt is cleared prematurely by
reading the interrupt register, in which case the interrupt is not seen by
The Loop.
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for
command block reads and writes, and found out that it didn't fix the
problem. Using PIO, only the first byte of the tag message comes
through. It might not be esp_scsi's fault, but there seems to be an
assumption that all devices support TCQ. Also, no SCSI-2 features seem
to be enabled in the chip by esp_scsi.

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

There is no need for PIO with the above hack.

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

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

which don't seem normal.

-Tuomas
Michael Schmitz
2013-09-11 10:12:19 UTC
Permalink
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for
command block reads and writes, and found out that it didn't fix the
Thanks, that does indeed absolve DMA.
Post by Tuomas Vainikka
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.)
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
which don't seem normal.
The acid test is - did it destroy your filesystem?

If not, I'd say you did brilliantly.

Thanks again,

Michael



On Tue, Sep 10, 2013 at 11:13 PM, Tuomas Vainikka
Post by Tuomas Vainikka
Post by Michael Schmitz
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
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.
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
Post by Michael Schmitz
The DMA transfer function can be changed to fetch less than seven bytes
from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
after sending the command to the ESP, instead of first setting up the DMA
then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to
PIO. It is also possible that the chip interrupt is cleared prematurely by
reading the interrupt register, in which case the interrupt is not seen by
The Loop.
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for
command block reads and writes, and found out that it didn't fix the
problem. Using PIO, only the first byte of the tag message comes through. It
might not be esp_scsi's fault, but there seems to be an assumption that all
devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip
by esp_scsi.
To cut the long story short, I hardwired TCQ off with a replacement function
for esp_slave_configure().
The replacement function resides in zorro_esp.c and is essentially doing the
same thing as the original if ESP_DEFAULT_TAGS was set to zero in
esp_scsi.h.
There is no need for PIO with the above hack.
I've attached a log of the module loading and some operations on the
attached hdd. Note that there are messages such as
[ 4627.040000] sd 0:0:0:0: [sda] Got wrong page
and
[ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.
which don't seem normal.
-Tuomas
Tuomas Vainikka
2013-09-11 13:08:35 UTC
Permalink
Post by Michael Schmitz
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for
command block reads and writes, and found out that it didn't fix the
Thanks, that does indeed absolve DMA.
Post by Tuomas Vainikka
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.
Post by Michael Schmitz
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
Tuomas Vainikka
2013-09-11 20:14:09 UTC
Permalink
Post by Tuomas Vainikka
Post by Michael Schmitz
Hello Tuomas,
Post by Tuomas Vainikka
Post by Michael Schmitz
That's the attitude - my suggestion was purely pragmatic, in order to
overcome that particular roadblock and see whether there's further
issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of
anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for
command block reads and writes, and found out that it didn't fix the
Thanks, that does indeed absolve DMA.
Post by Tuomas Vainikka
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.
Post by Michael Schmitz
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
Michael Schmitz
2013-09-26 13:44:46 UTC
Permalink
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.
Post by Tuomas Vainikka
Post by Michael Schmitz
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
Tuomas Vainikka
2013-09-26 14:04:31 UTC
Permalink
Post by 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.
Post by Tuomas Vainikka
Post by Michael Schmitz
What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or
higher? (Apologies for asking this - it will be in one of your old
logs but I cannot easily read these here.)
The drive you would find by searching with the model number in the
logs would point you to an IDE drive, which is actually connected to
a bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI
features. I also have a 'real' ST51080N that supports Fast SCSI-2
that I've also tested with the driver to no avail. I will double
check again with the real SCSI drive to ascertain that the bridge
adapter is not the culprit, just to make sure.
I'm fully aware the info would have been in the logs, but all I had to
work with was a dodgy XP box at my in-law's place, and not a lot of
time to poke around.
You have established that the SCSI bridge is responsible for a few odd
warnings but nothing serious, so I'd say we give your patched driver a
good workout on a number of Amiga m68k porter boxes, Unless you beat
me to it, I would suggest I provide a patch against Geert's latest
m68k development tree for someone else to integrate into the Debian
kernel package (would be a highly experimental one). Does that sound
fair?
Go ahead. I assume you can now open the attachments? If you could just
make one small modification; all controllers but Oktagon use a 40 MHz
clock. The zorro_esp driver versions I've been spamming to this list all
have carried a bad 20 MHz clock setting for the Blizzard 2060 board.

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

-Tuomas
Michael Schmitz
2013-09-27 09:17:47 UTC
Permalink
Hello Tuomas,
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
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
Geert Uytterhoeven
2013-09-11 14:48:34 UTC
Permalink
Post by Michael Schmitz
Post by Tuomas Vainikka
problem. Using PIO, only the first byte of the tag message comes through. It
might not be esp_scsi's fault, but there seems to be an assumption that all
devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip
by esp_scsi.
I'd have to check with DaveM, but such an assumption might in fact exist.
BTW, it would be nice to start CCing linux-***@vger.kernel.org and
David S. Miller <***@davemloft.net> on future discussions.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Tuomas Vainikka
2013-09-12 15:36:09 UTC
Permalink
Post by Geert Uytterhoeven
Post by Michael Schmitz
Post by Tuomas Vainikka
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.
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
Michael Schmitz
2013-09-26 13:50:19 UTC
Permalink
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
Post by Tuomas Vainikka
On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz
Post by Michael Schmitz
Post by Tuomas Vainikka
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.
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
David Miller
2014-04-04 20:28:30 UTC
Permalink
From: Tuomas Vainikka <***@aalto.fi>
Date: Thu, 12 Sep 2013 18:36:09 +0300
Post by Tuomas Vainikka
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.
Post by Tuomas Vainikka
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.
Michael Schmitz
2014-04-06 20:33:12 UTC
Permalink
Hello Dave, Tuomas,
Post by David Miller
Post by Tuomas Vainikka
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2014-04-07 03:39:24 UTC
Permalink
From: Michael Schmitz <***@gmail.com>
Date: Mon, 7 Apr 2014 08:33:12 +1200
Post by Michael Schmitz
Hello Dave, Tuomas,
Post by David Miller
Post by Tuomas Vainikka
Also, looking at the timeout formulae in the old NCR53C9x.c driver,
the values would be different for FAS216. Why was this dropped from
the modern esp_scsi?
I've never seen a formula for any ESP or FAS chip for the timeout
other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192
factor being used in the old NCR53C9x driver.
I haven't gone far enough back in the 53C9x revision history to be
certain. but it would seem to me that Kars de Jong added that FAS
special case.
Can you confirm that, Kars? Any recollection as to the reason?
Just as another reference point, I looked at the FreeBSD 'esp' driver
and it also uses the 8192 factor for all chips, including FAS216.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kars de Jong
2014-04-10 14:31:54 UTC
Permalink
Post by Michael Schmitz
Hello Dave, Tuomas,
Post by David Miller
Post by Tuomas Vainikka
Also, looking at the timeout formulae in the old NCR53C9x.c driver,
the values would be different for FAS216. Why was this dropped from
the modern esp_scsi?
I've never seen a formula for any ESP or FAS chip for the timeout
other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192
factor being used in the old NCR53C9x driver.
I haven't gone far enough back in the 53C9x revision history to be
certain. but it would seem to me that Kars de Jong added that FAS
special case.
Can you confirm that, Kars? Any recollection as to the reason?
That is the value that's in the data manual of the Symbios Logic
SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller).

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

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


Kind regards,

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

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

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

Cheers,

Michael
Kars de Jong
2014-04-13 14:47:45 UTC
Permalink
Hi Michael,
Post by Michael Schmitz
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.
Post by Michael Schmitz
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.
Michael Schmitz
2014-04-13 22:38:09 UTC
Permalink
Hi Kars,

thanks for the PDFs!
Post by Kars de Jong
Bit 2 SCSI-2
Setting this bit allows the FSC to support two new features adopted in
SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2
commands. These features can also be set independently in the Config 3
register.
Tagged-Queueing
When this bit is set and the FSC is selected with ATN (Attention), it
will request either one or three message bytes depending on whether
ATN remains true or goes false. If ATN is still true after the first
byte has been received, the FSC may request two more message bytes
before switching to Command phase. If ATN goes false, it will switch
to Command phase after the first message byte. When the bit is not set
it will request a single message byte (as a target) when selected with
ATN, and abort the selection sequence (as an initiator) if the target
does not switch to Command phase after one message byte has been
transferred.
That appears to be our problem if I recall correctly Tuomas' debugging
report. (reselection, not selection as initiator). As
esp_slave_configure() enables queue tags regardless of chip config,
we'd best make certain the chip is configured correctly.

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

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

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

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

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

return 0;
Post by Kars de Jong
Group 2 Commands
(seems to only be relevant for target mode).
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2014-04-14 02:14:14 UTC
Permalink
From: Michael Schmitz <***@gmail.com>
Date: Mon, 14 Apr 2014 10:38:09 +1200
Post by Michael Schmitz
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?
...
Post by Michael Schmitz
Post by Kars de Jong
Group 2 Commands
(seems to only be relevant for target mode).
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.

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

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

But oddly in the NCR53CX docs:

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

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

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

Can we try testing the following patch?

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

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

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

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
Tuomas Vainikka
2014-04-14 05:05:34 UTC
Permalink
Post by David Miller
Date: Mon, 14 Apr 2014 10:38:09 +1200
Post by Michael Schmitz
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?
...
Post by Michael Schmitz
Post by Kars de Jong
Group 2 Commands
(seems to only be relevant for target mode).
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.
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.
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
I'll test these out soon.

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

-Tuomas
Michael Schmitz
2014-04-14 08:51:16 UTC
Permalink
Hi Tuomas,
Post by Tuomas Vainikka
Post by David Miller
Post by Michael Schmitz
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.
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.
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
I'll test these out soon.
Michael, where can I pull the latest version of zorro_esp?
Not sure my patch had ever made it into Geert's m68k-queue - except for
the patch in my previous mail, my zorro_esp.c is still the same as I
got from you in October last year. The project has been on the back
burner for too long ...

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

Cheers,

Michael
Geert Uytterhoeven
2014-05-25 08:56:09 UTC
Permalink
Hi Michael,

[sorry for the long delay]
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 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Michael Schmitz
2014-05-26 01:15:22 UTC
Permalink
Hi Geert,
Post by Geert Uytterhoeven
[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.
Post by Geert Uytterhoeven
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael Schmitz
2014-04-14 09:01:02 UTC
Permalink
Hi Dave,
Post by David Miller
Post by Michael Schmitz
Post by Kars de Jong
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.
Post by David Miller
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.
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.
Post by David Miller
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
Post by David Miller
====================
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
Tuomas Vainikka
2014-05-04 11:41:04 UTC
Permalink
Post by Michael Schmitz
Hi Dave,
Post by David Miller
Post by Michael Schmitz
Post by Kars de Jong
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.
Post by David Miller
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.
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.
Post by David Miller
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
Post by David Miller
====================
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
Hello,

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

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

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

-Tuomas
Geert Uytterhoeven
2013-08-18 09:42:59 UTC
Permalink
On Sun, Aug 18, 2013 at 11:14 AM, 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.
correct iomappings for the registers, nor do I know about the correct sizes
for them. I have no idea where to use physical addresses and where to use
virtual addresses...
When the CPU accesses memory, you have to use virtual addresses.
When the DMA engine accesses memory, it has to use physical addresses.

Typically the DMA API is used to do the conversion
What is the difference between ioremap() and ZTWO_VADDR() and which one
should be used where?
ioremap() is the generic way to map hardware registers into the CPU's virtual
address space.

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

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Tuomas Vainikka
2013-08-18 12:25:54 UTC
Permalink
Post by Geert Uytterhoeven
On Sun, Aug 18, 2013 at 11:14 AM, 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.
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
Loading...