Experimental Amiga Zorro ESP driver
cover Experimental Amiga Zorro ESP driver
Geert,
other than 'it compiles', I can't really say much about this one. I've done what seemed necessary to do the ESP probe setup in the zorro driver framework (using the NCR7xx driver as a guideline), and used the old Blizzard 2060 driver as a model for the DMA setup.
To adapt to another style of ESP integration, the DMA setup function will need to be changed. The simplest way to cater for multipe boards in this driver may be to provide a separate DMA setup function for each, and substitute the correct one for the default esp_ops field in the driver probe. Please correct me if you see a better or simpler way.
Posting to the list in the hope that someone will be able to compile and test this. I will be increasingly busy at work over the next months, and may not have much opportunity to work on this until October. Ingo had offered a setup for remote debugging and testing, but I've been slow to get started on that, and the machine now moves to FU Berlin if I understood right.
Cheers,
Michael
[PATCH 1/2] m68k/amiga - Zorro ESP SCSI Makefile/Kconfig support [PATCH 2/2] m68k/amiga - Zorro ESP: convert old driver to ESP core
PATCH 1/2 m68k/amiga - Zorro ESP SCSI Makefile/Kconfig support
--- drivers/scsi/Kconfig | 16 ++++++++++++++++ drivers/scsi/Makefile | 1 + 2 files changed, 17 insertions(+), 0 deletions(-)
drivers/scsi/Kconfig +16 -0
@@ -1644,6 +1644,22 @@ config SCSI_ZORRO7XX accelerator card for the Amiga 1200, - the SCSI controller on the GVP Turbo 040/060 accelerator. +config SCSI_ZORRO_ESP + tristate "Zorro ESP SCSI support" + depends on ZORRO && SCSI + select SCSI_SPI_ATTRS + help + Support for various ESP-based SCSI controllers on Zorro + expansion boards for the Amiga. + This includes: + - the Amiga 4091 Zorro III SCSI-2 controller, + - the MacroSystem Development's WarpEngine Amiga SCSI-2 controller + (info at + <http://www.lysator.liu.se/amiga/ar/guide/ar310.guide?FEATURE5>), + - the SCSI controller on the Phase5 Blizzard PowerUP 603e+ + accelerator card for the Amiga 1200, + - the SCSI controller on the GVP Turbo 040/060 accelerator. + config ATARI_SCSI tristate "Atari native SCSI support" depends on ATARI && SCSI
drivers/scsi/Makefile +1 -0
@@ -46,6 +46,7 @@ obj-$(CONFIG_INFINIBAND_ISER) += libiscsi.o obj-$(CONFIG_ISCSI_BOOT_SYSFS) += iscsi_boot_sysfs.o obj-$(CONFIG_SCSI_A4000T) += 53c700.o a4000t.o obj-$(CONFIG_SCSI_ZORRO7XX) += 53c700.o zorro7xx.o +obj-$(CONFIG_SCSI_ZORRO_ESP) += esp_scsi.o zorro_esp.o obj-$(CONFIG_A3000_SCSI) += a3000.o wd33c93.o obj-$(CONFIG_A2091_SCSI) += a2091.o wd33c93.o obj-$(CONFIG_GVP11_SCSI) += gvp11.o wd33c93.o
Signature · 1 line
1.7.0.4
PATCH 2/2 m68k/amiga - Zorro ESP: convert old driver to ESP core
In reply to Michael Schmitz--- drivers/scsi/zorro_esp.c | 414 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 414 insertions(+), 0 deletions(-) create mode 100644 drivers/scsi/zorro_esp.c
drivers/scsi/zorro_esp.c new file +414 -0
@@ -0,0 +1,414 @@ +/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems. +* +* Copyright (C) 1996 Jesper Skov ([email protected]) +* +* Copyright (C) 2011 Michael Schmitz ([email protected]) for +* migration to ESP SCSI core +*/ +/* +* ZORRO bus code from: +*/ +/* +* Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux. +* Amiga MacroSystemUS WarpEngine SCSI controller. +* Amiga Technologies/DKB A4091 SCSI controller. +* +* Written 1997 by Alan Hourihane <[email protected]> +* plus modifications of the 53c7xx.c driver to support the Amiga. +* +* Rewritten to use 53c700.c by Kars de Jong <[email protected]> +*/ + +#include <linux/module.h> +#include <linux/init.h> +#include <linux/interrupt.h> +#include <linux/dma-mapping.h> +#include <linux/scatterlist.h> +#include <linux/zorro.h> +#include <linux/slab.h> + +#include <asm/page.h> +#include <asm/pgtable.h> +#include <asm/cacheflush.h> +#include <asm/amigahw.h> +#include <asm/amigaints.h> + +#include <scsi/scsi_host.h> +#include <scsi/scsi_transport_spi.h> + +#include "esp_scsi.h" + +MODULE_AUTHOR ("Michael Schmitz <[email protected]>" ); +MODULE_DESCRIPTION ("Amiga Zorro NCR5C9x (ESP) driver" ); +MODULE_LICENSE ("GPL" ); + + +static struct scsi_host_template zorro_esp_scsi_driver_template = { + .proc_name ="zorro-esp" , + .this_id =7 , + .module =THIS_MODULE , +}; + +static struct zorro_driver_data { +const char *name; +unsigned long offset; +unsigned long dma_offset; +int absolute; +int zorro3;/* offset is absolute address */ +} zorro_esp_driver_data[] = { + { .name ="CyberStormI" , .offset =0xf400 , .dma_offset =0xf800 }, + { .name ="CyberStormII" , .offset =0x1ff03 , .dma_offset =0x1ff43 }, + { .name ="Blizzard 2060" , .offset =0x1ff00 , .dma_offset =0x1ffe0 }, + { .name ="Blizzard 1230" , .offset =0x8000 , .dma_offset =0x10000 }, + { .name ="Blizzard 1230II" , .offset =0x10000 , .dma_offset =0x10021 }, + { .name ="Fastlane" , .offset =0x1000001 , .dma_offset =0x1000041 , .zorro3 =1 }, + {0 } +}; + +static struct zorro_device_id zorro_esp_zorro_tbl[] = { + { + .id =ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM , + .driver_data = (unsigned long )&zorro_esp_driver_data[0 ], + }, + { + .id =ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060 , + .driver_data = (unsigned long )&zorro_esp_driver_data[0 ], + }, + { + .id =ZORRO_PROD_PHASE5_CYBERSTORM_MK_II , + .driver_data = (unsigned long )&zorro_esp_driver_data[1 ], + }, + { + .id =ZORRO_PROD_PHASE5_BLIZZARD_2060 , + .driver_data = (unsigned long )&zorro_esp_driver_data[2 ], + }, + { + .id =ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260 , + .driver_data = (unsigned long )&zorro_esp_driver_data[3 ], + }, + { + .id =ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060 , + .driver_data = (unsigned long )&zorro_esp_driver_data[4 ], + }, + {0 } +}; +MODULE_DEVICE_TABLE (zorro, zorro_esp_zorro_tbl); + +/* The controller registers can be found in the Z2 config area at these +* offsets: +*/ +#define BLZ2060_ESP_ADDR 0x1ff00 +#define BLZ2060_DMA_ADDR 0x1ffe0 + + +/* The Blizzard 2060 DMA interface +* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +* Only two things can be programmed in the Blizzard DMA: +* 1) The data direction is controlled by the status of bit 31 (1 = write) +* 2) The source/dest address (word aligned, shifted one right) in bits 30-0 +* +* Figure out interrupt status by reading the ESP status byte. +*/ +struct blz2060_dma_registers { +volatile unsigned char dma_led_ctrl;/* DMA led control [0x000] */ +unsigned char dmapad1[0x0f ]; +volatile unsigned char dma_addr0;/* DMA address (MSB) [0x010] */ +unsigned char dmapad2[0x03 ]; +volatile unsigned char dma_addr1;/* DMA address [0x014] */ +unsigned char dmapad3[0x03 ]; +volatile unsigned char dma_addr2;/* DMA address [0x018] */ +unsigned char dmapad4[0x03 ]; +volatile unsigned char dma_addr3;/* DMA address (LSB) [0x01c] */ +}; + +#define BLZ2060_DMA_WRITE 0x80000000 + +/* DMA control bits */ +#define BLZ2060_DMA_LED 0x02/* HD led control 1 = off */ + + +/* +* m68k always assumes readl/writel operate on little endian +* mmio space; this is wrong at least for Sun3x, so we +* need to workaround this until a proper way is found +*/ +#if 0 +#define dma_read32 (REG ) \ + readl(esp->dma_regs + (REG)) +#define dma_write32 (VAL ,REG ) \ + writel((VAL), esp->dma_regs + (REG)) +#else +#define dma_read32 (REG ) \ + *(volatile u32 *)(esp->dma_regs + (REG)) +#define dma_write32 (VAL ,REG ) \ + do { *(volatile u32 *)(esp->dma_regs + (REG)) = (VAL); } while (0) +#endif + +/* +* On all implementations except for the Oktagon, padding between ESP +* registers is three bytes. +* On Oktagon, it is one byte - use a different accessor there. +* +* Oktagon currently unsupported! +*/ + +static void zorro_esp_write8 (struct esp *esp,u8 val,unsigned long reg) +{ +writeb (val, esp->regs + (reg *4UL )); +} + +static u8 zorro_esp_read8 (struct esp *esp,unsigned long reg) +{ +return readb (esp->regs + (reg *4UL )); +} + +static dma_addr_t zorro_esp_map_single (struct esp *esp,void *buf, +size_t sz,int dir) +{ +return dma_map_single (esp->dev, buf, sz, dir); +} + +static int zorro_esp_map_sg (struct esp *esp,struct scatterlist *sg, +int num_sg,int dir) +{ +return dma_map_sg (esp->dev, sg, num_sg, dir); +} + +static void zorro_esp_unmap_single (struct esp *esp,dma_addr_t addr, +size_t sz,int dir) +{ +dma_unmap_single (esp->dev, addr, sz, dir); +} + +static void zorro_esp_unmap_sg (struct esp *esp,struct scatterlist *sg, +int num_sg,int dir) +{ +dma_unmap_sg (esp->dev, sg, num_sg, dir); +} + +static int zorro_esp_irq_pending (struct esp *esp) +{ +/* check ESP status register; DMA has no status reg. */ +if (zorro_esp_read8 (esp,ESP_STATUS ) &ESP_STAT_INTR ) +return 1 ; + +return 0 ; +} + +static void zorro_esp_reset_dma (struct esp *esp) +{ +/* nothing to do here */ +} + +static void zorro_esp_dma_drain (struct esp *esp) +{ +/* nothing to do here */ +} + +static void zorro_esp_dma_invalidate (struct esp *esp) +{ +/* nothing to do here */ +} + +static void zorro_esp_send_dma_cmd (struct esp *esp,u32 addr,u32 esp_count, +u32 dma_count,int write,u8 cmd) +{ +struct blz2060_dma_registers *dregs = + (struct blz2060_dma_registers *) (esp->dma_regs); + +BUG_ON (!(cmd &ESP_CMD_DMA )); +zorro_esp_write8 (esp, (esp_count >>0 ) &0xff ,ESP_TCLOW ); +zorro_esp_write8 (esp, (esp_count >>8 ) &0xff ,ESP_TCMED ); + +/* +* This will differ among Amiga ESP implementations - DMA setup! +*/ + +if (write) +cache_clear (addr, esp_count); +else +cache_push (addr, esp_count); + +/* On the Sparc, DMA_ST_WRITE means "move data from device to memory" +* so when (write) is true, it actually means READ (from the ESP)! +*/ + addr >>=1 ; +if (write) + addr &= ~(BLZ2060_DMA_WRITE ); +else + addr |=BLZ2060_DMA_WRITE ; + + dregs->dma_addr3 = (addr ) &0xff ; + dregs->dma_addr2 = (addr >>8 ) &0xff ; + dregs->dma_addr1 = (addr >>16 ) &0xff ; + dregs->dma_addr0 = (addr >>24 ) &0xff ; + +scsi_esp_cmd (esp, cmd); +} + +static int zorro_esp_dma_error (struct esp *esp) +{ +/* nothing to do here - there seems to be no way to check for DMA errors */ +return 0 ; +} + +static const struct esp_driver_ops zorro_esp_ops = { + .esp_write8 = zorro_esp_write8, + .esp_read8 = zorro_esp_read8, + .map_single = zorro_esp_map_single, + .map_sg = zorro_esp_map_sg, + .unmap_single = zorro_esp_unmap_single, + .unmap_sg = zorro_esp_unmap_sg, + .irq_pending = zorro_esp_irq_pending, + .reset_dma = zorro_esp_reset_dma, + .dma_drain = zorro_esp_dma_drain, + .dma_invalidate = zorro_esp_dma_invalidate, + .send_dma_cmd = zorro_esp_send_dma_cmd, + .dma_error = zorro_esp_dma_error, +}; + +static int zorro_esp_init_one (struct zorro_dev *z, +const struct zorro_device_id *ent) +{ +struct scsi_host_template *tpnt = &zorro_esp_scsi_driver_template; +struct Scsi_Host *host; +struct esp *esp; +struct zorro_driver_data *zdd; +unsigned long board, ioaddr, dmaaddr, esp_base; +int err = -ENOMEM ; + + board =zorro_resource_start (z); + zdd = (struct zorro_driver_data *)ent->driver_data; + +if (zdd->absolute) { + ioaddr = zdd->offset; + dmaaddr = zdd->dma_offset; + }else { + ioaddr = board + zdd->offset; + dmaaddr = board + zdd->dma_offset; + } + +if (!zorro_request_device (z, zdd->name)) { +printk (KERN_ERR "zorro_esp: cannot reserve region 0x%lx, abort\n" , + board); +return -EBUSY ; + } + +/* Fill in the required pieces of hostdata */ +if (ioaddr >0x01000000 ) + esp_base =ioremap (ioaddr,zorro_resource_len (z)); +else + esp_base = (void __iomem *)ZTWO_VADDR (ioaddr); + + zorro_esp_scsi_driver_template.name = zdd->name; + +/* and register the chip */ + host =scsi_host_alloc (tpnt,sizeof (struct esp )); + +if (!host) { +printk (KERN_ERR "zorro_esp: No host detected; " +"board configuration problem?\n" ); + goto out_free; + } + + host->max_id =8 ; + esp =shost_priv (host); + + esp->host = host; + esp->dev = z; + esp->ops = &zorro_esp_ops; + + esp->regs =ioremap_nocache (ioaddr,0x20 ); +if (!esp->regs) + goto fail_unmap_regs; + + esp->dma_regs =ioremap_nocache (dmaaddr,0x20 ); + + esp->command_block =dma_alloc_coherent (esp->dev,32 , + &esp->command_block_dma, +GFP_KERNEL ); +if (!esp->command_block) + goto fail_unmap_regs_dma; + + host->irq =IRQ_AMIGA_PORTS ; + err =request_irq (host->irq, scsi_esp_intr,IRQF_SHARED , +"Amiga Zorro ESP" , esp); +if (err <0 ) + goto fail_unmap_command_block; + + esp->scsi_id =7 ; + esp->host->this_id = esp->scsi_id; + esp->scsi_id_mask = (1 << esp->scsi_id); + esp->cfreq =20000000 ; + +dev_set_drvdata (&z->dev, esp); + + err =scsi_esp_register (esp, &z->dev); +if (err) + goto fail_free_irq; + +zorro_set_drvdata (z, host); +scsi_scan_host (host); + +return 0 ; + +fail_free_irq: +free_irq (host->irq, esp); +fail_unmap_command_block: +dma_free_coherent (esp->dev,16 , + esp->command_block, + esp->command_block_dma); +fail_unmap_regs_dma: +iounmap (esp->dma_regs); +fail_unmap_regs: +iounmap (esp->regs); +scsi_host_put (host); +out_free: +if (ioaddr >0x01000000 ) +iounmap (esp_base); +out_release: +zorro_release_device (z); + +return -ENODEV ; +} + +static void zorro_esp_remove_one (struct zorro_dev *z) +{ +struct Scsi_Host *host =zorro_get_drvdata (z); +struct esp *esp =dev_get_drvdata (&z->dev); +unsigned int irq = esp->host->irq; +u32 val; + +scsi_esp_unregister (esp); + +/* Disable interrupts. Perhaps use disable_irq instead ... */ + +free_irq (irq, esp); +dma_free_coherent (esp->dev,16 , + esp->command_block, + esp->command_block_dma); + +scsi_host_put (esp->host); + +zorro_release_device (z); +} + +static struct zorro_driver zorro_esp_driver = { + .name ="zorro_esp-scsi" , + .id_table = zorro_esp_zorro_tbl, + .probe = zorro_esp_init_one, + .remove = zorro_esp_remove_one, +}; + +static int __init zorro_esp_scsi_init (void ) +{ +return zorro_register_driver (&zorro_esp_driver); +} + +static void __exit zorro_esp_scsi_exit(void) +{ +zorro_unregister_driver (&zorro_esp_driver); +} + +module_init (zorro_esp_scsi_init); +module_exit (zorro_esp_scsi_exit);
Signature · 1 line
1.7.0.4
Quoted 7 lines · Michael Schmitz
Geert,
other than 'it compiles', I can't really say much about this one. I've done what seemed necessary to do the ESP probe setup in the zorro driver framework (using the NCR7xx driver as a guideline), and used the old Blizzard 2060 driver as a model for the DMA setup.
Quoted 5 lines
To adapt to another style of ESP integration, the DMA setup function will need to be changed. The simplest way to cater for multipe boards in this driver may be to provide a separate DMA setup function for each, and substitute the correct one for the default
esp_opsfield 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
Quoted 15 lines · Tuomas Vainikka
Quoted 7 lines · Michael Schmitz
Geert,
other than 'it compiles', I can't really say much about this one. I've done what seemed necessary to do the ESP probe setup in the zorro driver framework (using the NCR7xx driver as a guideline), and used the old Blizzard 2060 driver as a model for the DMA setup.
Quoted 5 lines
To adapt to another style of ESP integration, the DMA setup function will need to be changed. The simplest way to cater for multipe boards in this driver may be to provide a separate DMA setup function for each, and substitute the correct one for the default
esp_opsfield in the driver probe. Please correct me if you see a better or simpler way.Thank you for rewriting the driver.
Quoted 8 lines
I copypasted the appropriate DMA code from
blz1230.c, and added some code to switch to the appropriate function. I compiled the module, and was able to insert and remove it.The dmesg output is attached. I also attached the modified
zorro_esp.c.There is a HDD attached to the SCSI bus, but the scan does not take place.
The chip on the controller is a FAS216, but it is identified as a FAS236. Does that matter?
I got a little further, but now there seems to be something wrong with the IRQ:
[ 297.720000] esp: esp0, regs[80ea8000:80eb0000] irq[2] [ 297.730000] esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7 [ 300.750000] scsi0 : esp [ 301.020000] scsi 0:0:1:0: Direct-Access SAMSUNG SP1213N TL10 PQ: 0 ANSI: 2 [ 301.030000] scsi target0:0:1: Beginning Domain Validation [ 301.060000] scsi target0:0:1: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15) [ 301.090000] scsi target0:0:1: Domain Validation skipping write tests [ 301.100000] scsi target0:0:1: Ending Domain Validation [ 301.880000] esp: esp0: Reconnect IRQ2 timeout [ 332.040000] esp: esp0: Aborting command [0f9998a0:12] [ 332.040000] esp: esp0: Current command [0f999940:25] [ 332.040000] esp: esp0: Queued command [0f9998a0:12] [ 332.040000] esp: esp0: Active command [0f999940:25] [ 332.040000] esp: esp0: Dumping command log
...
I attached a full log containing the dmesg output from both probing and removing the module.
-Tuomas
HelloTuomas,
Quoted 14 lines · Tuomas Vainikka
Quoted 13 lines · Michael Schmitz
Quoted 12 lines
Geert,
other than 'it compiles', I can't really say much about this one. I've done what seemed necessary to do the ESP probe setup in the zorro driver framework (using the NCR7xx driver as a guideline), and used the old Blizzard 2060 driver as a model for the DMA setup.
To adapt to another style of ESP integration, the DMA setup function will need to be changed. The simplest way to cater for multipe boards in this driver may be to provide a separate DMA setup function for each, and substitute the correct one for the default
esp_opsfield in the driver probe. Please correct me if you see a better or simpler way.
Quoted 4 lines
Quoted 4 lines
Thank you for rewriting the driver.
I copypasted the appropriate DMA code from
blz1230.c, and added some code to switch to the appropriate function. I compiled the module, and was able to insert and remove it.
Thanks, I will merge that with my current version of the driver. Thanks also for testing!
Quoted 6 lines
Quoted 6 lines
The dmesg output is attached. I also attached the modified
zorro_esp.c.There is a HDD attached to the SCSI bus, but the scan does not take place.
The chip on the controller is a FAS216, but it is identified as a FAS236. Does that matter?
I would not think so - David Miller as author of the ESP core might know better though. The m68k mac esp driver is the only one I ever worked on - fifteen years ago.
Quoted 12 lines
I got a little further, but now there seems to be something wrong with the IRQ:
[ 297.720000] esp: esp0, regs[80ea8000:80eb0000] irq[2] [ 297.730000] esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7 [ 300.750000] scsi0 : esp [ 301.020000] scsi 0:0:1:0: Direct-Access SAMSUNG SP1213N TL10 PQ: 0 ANSI: 2 [ 301.030000] scsi target0:0:1: Beginning Domain Validation [ 301.060000] scsi target0:0:1: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15) [ 301.090000] scsi target0:0:1: Domain Validation skipping write tests [ 301.100000] scsi target0:0:1: Ending Domain Validation [ 301.880000] esp: esp0: Reconnect IRQ2 timeout
Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? It looks to me as though all DMA transfers fail (the first command to fail is READ_CAPACITY which would usually be issued right after IDENTIFY IIRC).
Quoted 8 lines
[ 332.040000] esp: esp0: Aborting command [0f9998a0:12] [ 332.040000] esp: esp0: Current command [0f999940:25] [ 332.040000] esp: esp0: Queued command [0f9998a0:12] [ 332.040000] esp: esp0: Active command [0f999940:25] [ 332.040000] esp: esp0: Dumping command log...
I attached a full log containing the dmesg output from both probing and removing the module.
Thanks, I will try to make sense of the log...
Cheers,
Michael
Quoted 3 lines
-Tuomas
<zorro_esp.c.gz><zorro_esp_modprobe2.cap.gz>
Quoted 4 lines · Michael Schmitz
Quoted 2 lines
[ 301.880000] esp: esp0: Reconnect IRQ2 timeoutAre 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 isREAD_CAPACITYwhich would usually be issued right after IDENTIFY IIRC).
root@amiga:/# cat /proc/interrupts
CPU0
2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP
6: 456970 auto CIAB
8: 38239 amiga serial TX
9: 0 amiga floppy_dma
12: 315934 amiga fb vertb handler
13: 315741 amiga serial status
15: 0 amiga DMA sound
19: 401 amiga serial RX
23: 1 cia floppy_timer
25: 0 cia amikbd
27: 456971 cia timer
ERR: 0Seems 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
Tuomas,
Quoted 20 lines
Quoted 4 lines
Quoted 2 lines
[ 301.880000] esp: esp0: Reconnect IRQ2 timeoutAre 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 isREAD_CAPACITYwhich would usually be issued right after IDENTIFY IIRC).root@amiga:/# cat /proc/interrupts CPU0 2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP 6: 456970 auto CIAB 8: 38239 amiga serial TX 9: 0 amiga floppy_dma 12: 315934 amiga fb vertb handler 13: 315741 amiga serial status 15: 0 amiga DMA sound 19: 401 amiga serial RX 23: 1 cia floppy_timer 25: 0 cia amikbd 27: 456971 cia timer ERR: 0
Quoted 1 line
Seems like IRQ2 is very popular, so it's hard to say which device has generated the interrupts...
Yep - you'll be guaranteed to get a few IDE interrupts just by calling up cat - might be possible to get away without too much interrupts generated if it's all in the buffer cache - try whether the interrupt count changes after a few repetitions of that command.
Might require more elaborate IRQ bookkeeping though.
Quoted 1 line
Should the assigned irq name match the module name?
No, that's just the string passed to request_irq. I'm not aware of a policy mandating use of module names there.
Another question, after I had a look at your driver: are you certain mapping a size of 0x20 is enough for the Mark IV DMA engine? The latch register is at offset 0x8000 from the address register ...
All (or most) other ESP drivers use 16 bit transfer counts only - you set the 1230 to use 24 bit, can it actually do that?
Cheers,
Michael
Quoted 1 line · Michael Schmitz
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 301.880000] esp: esp0: Reconnect IRQ2 timeout
Beware that this message (incl. the number) is hardcoded in drivers/scsi/esp_scsi.c:
if (i == ESP_RESELECT_TAG_LIMIT) {
printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n",
esp->host->unique_id);
return NULL;
}The driver prints "IRQ1" or "IRQ2".
Fortunately, IRQ_AMIGA_PORTS is 2, but this is purely coincidentally...
Quoted 23 lines
Quoted 19 lines
Quoted 3 lines
Are there interrupts logged for IRQ2 at all (cat
/proc/interrupts)? It looks to me as though all DMA transfers fail (the first command to fail isREAD_CAPACITYwhich would usually be issued right after IDENTIFY IIRC).root@amiga:/# cat /proc/interrupts CPU0 2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP 6: 456970 auto CIAB 8: 38239 amiga serial TX 9: 0 amiga floppy_dma 12: 315934 amiga fb vertb handler 13: 315741 amiga serial status 15: 0 amiga DMA sound 19: 401 amiga serial RX 23: 1 cia floppy_timer 25: 0 cia amikbd 27: 456971 cia timer ERR: 0Quoted 2 lines
Seems like IRQ2 is very popular, so it's hard to say which device has generated the interrupts...
Quoted 6 lines
Yep - you'll be guaranteed to get a few IDE interrupts just by calling up cat - might be possible to get away without too much interrupts generated if it's all in the buffer cache - try whether the interrupt count changes after a few repetitions of that command.
Might require more elaborate IRQ bookkeeping though.
I guess scsi_esp_intr() is called a lot, as it's a shared interrupt? Can you add some debug prints there, to see if any of the conditions the esp core checks are met?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Geert,
Quoted 14 lines · Michael Schmitz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
[ 301.880000] esp: esp0: Reconnect IRQ2 timeoutBeware that this message (incl. the number) is hardcoded in
drivers/scsi/esp_scsi.c:if (i == ESP_RESELECT_TAG_LIMIT) { printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n", esp->host->unique_id); return NULL; }
Quoted 4 lines
The driver prints "IRQ1" or "IRQ2".
Fortunately,
IRQ_AMIGA_PORTSis 2, but this is purely coincidentally...
The driver attempts to DMA two bytes - can the DMA on the Zorro ESP cards handle such short transfers?
I'll also need to check the command_block and command_block_dma addresses - does the DMA require virtual or physical addresses?
Quoted 28 lines
Quoted 28 lines
Quoted 20 lines
Quoted 5 lines
Are there interrupts logged for IRQ2 at all (cat
/proc/interrupts)? It looks to me as though all DMA transfers fail (the first command to fail isREAD_CAPACITYwhich would usually be issued right after IDENTIFY IIRC).root@amiga:/# cat /proc/interrupts CPU0 2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP 6: 456970 auto CIAB 8: 38239 amiga serial TX 9: 0 amiga floppy_dma 12: 315934 amiga fb vertb handler 13: 315741 amiga serial status 15: 0 amiga DMA sound 19: 401 amiga serial RX 23: 1 cia floppy_timer 25: 0 cia amikbd 27: 456971 cia timer ERR: 0Quoted 3 lines
Seems like IRQ2 is very popular, so it's hard to say which device has generated the interrupts...
Yep - you'll be guaranteed to get a few IDE interrupts just by calling up cat - might be possible to get away without too much interrupts generated if it's all in the buffer cache - try whether the interrupt count changes after a few repetitions of that command.
Quoted 5 lines
Quoted 2 lines
Might require more elaborate IRQ bookkeeping though.
I guess
scsi_esp_intr()is called a lot, as it's a shared interrupt?
That's right - it will indeed be called a lot.
Quoted 3 lines
Can you add some debug prints there, to see if any of the conditions the esp core checks are met?
The code in question polls for completion in the ESP chip interrupt register, so checking in scsi_esp_intr won't help there. I suspect the ESP gets stuck because the DMA operation never completes. Wonder whether we can just do PIO in send_dma_cmd() in these cases ...
Cheers,
Michael
Quoted 2 lines · Michael Schmitz
I'll also need to check the
command_blockandcommand_block_dmaaddresses - does the DMA require virtual or physical addresses?
Physical, of course.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Geert,
Quoted 8 lines · Michael Schmitz
Quoted 4 lines
I'll also need to check the
command_blockandcommand_block_dmaaddresses - 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
Quoted 5 lines · Michael Schmitz
Geert,
Quoted 4 lines · Michael Schmitz
Quoted 2 lines
I'll also need to check the
command_blockandcommand_block_dmaaddresses - does the DMA require virtual or physical addresses?
Quoted 9 lines
Quoted 1 line
Physical, of course.
:-) VDMA was invented a bit later ...
I'll go check the usage of the DMA API calls again, but as the driver seems to do DMA fine until the short transfer, that seems the most likely cause. PIO for
dma_count< 7 might be an option.I see transfers with esp_count=1 and dma_count=7 in the log - wonder why that works but the short 2/2 byte case does not.
Is it possible that the problem is with memory alignment?
http://fxr.watson.org/fxr/source/arch/amiga/dev/bzivsc.c?v=NETBSD#L360
https://groups.google.com/d/msg/comp.sys.amiga.hardware/FXwaSFoAPxc/zsXeP7PB6RoJ
-Tuomas
Quoted 1 line · Tuomas Vainikka
Is it possible that the problem is with memory alignment?
Not here:
[ 2549.540000] zorro_esp: esp_count = 2, dma_count = 2, addr = 0x7fbe1000. Writing. [ 2549.540000] esp: esp0: Reconnect IRQ2 timeout
addr = 0x7fbe1000, which is even PAGE_SIZE aligned.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 10 lines · Michael Schmitz
Geert,
Quoted 5 lines · Michael Schmitz
Quoted 2 lines
I'll also need to check the
command_blockandcommand_block_dmaaddresses - does the DMA require virtual or physical addresses?Physical, of course.
:-) VDMA was invented a bit later ...
Quoted 8 lines
I'll go check the usage of the DMA API calls again, but as the driver seems to do DMA fine until the short transfer, that seems the most likely cause. PIO for
dma_count< 7 might be an option.I see transfers with esp_count=1 and dma_count=7 in the log - wonder why that works but the short 2/2 byte case does not.
Cheers,
Michael
I guess those two bytes have something to do with target (re)selection... There are two different ways of attempting to read these bytes in the code, one is reading them from the FIFO byte by byte, and the other way is to setup a DMA read (write from device). The two different schemes are used in two different functions, and I do not understand why one method would be preferred over the other when comparing these functions.
I think I managed to find these two bytes; They are not ready for DMA, but are sitting in the FIFO waiting to be read. So the loop before the "IRQ2 timeout" is waiting for an interrupt that would tell that the DMA transfer has finished.
...
[13433.390000] ESP: Disconnecting tgt[1] tag[20:0] [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x97, 2 bytes in FIFO. [13433.400000] ESP: intr sreg[97] seqreg[04] sreg2[00] ireg[0c] [13433.400000] ESP: reconnect tag, zorro_esp_irq_pending(): ESP_STATUS = 0x97, 0 bytes in FIFO. [13433.400000] IRQ(0:10:97), zorro_esp: esp_count = 2, dma_count = 2, addr = 0x7fa59000. Writing. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO.
...
Remember that write is read :)
Now, I guess, I have to check whether those two bytes contain the right information...
-Tuomas
Tuomas,
Quoted 1 line
I guess those two bytes have something to do with target (re)selection... There are two different ways of attempting to read these bytes in the code, one is reading them from the FIFO byte by byte, and the other way is to setup a DMA read (write from device). The two different schemes are used in two different functions, and I do not understand why one method would be preferred over the other when comparing these functions.
What the driver attempts to read on reselection are the tag bytes that were used in the previous disconnect. These have to match otherwise we are not reselecting the command we need.
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
Quoted 2 lines
I think I managed to find these two bytes; They are not ready for DMA, but are sitting in the FIFO waiting to be read. So the loop before the "IRQ2 timeout" is waiting for an interrupt that would tell that the DMA transfer has finished.
The loop checks whether the ESP status indicates the transfer is done - if the bytes are still stuck in the FIFO I'd guess the DMA does not bother to transfer for such small transfer counts.
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO after sending the command to the ESP, instead of first setting up the DMA then sending the command),
I haven't yet merged your changes into my source - will try to do that tomorrow.
Cheers,
Michael
Quoted 29 lines
...
[13433.390000] ESP: Disconnecting tgt[1] tag[20:0] [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x97, 2 bytes in FIFO. [13433.400000] ESP: intr sreg[97] seqreg[04] sreg2[00] ireg[0c] [13433.400000] ESP: reconnect tag, zorro_esp_irq_pending(): ESP_STATUS = 0x97, 0 bytes in FIFO. [13433.400000] IRQ(0:10:97), zorro_esp: esp_count = 2, dma_count = 2, addr = 0x7fa59000. Writing. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO. [13433.400000] zorro_esp_irq_pending(): ESP_STATUS = 0x17, 2 bytes in FIFO....
Remember that write is read :)Now, I guess, I have to check whether those two bytes contain the right information...
-Tuomas
<zesp014.cap.gz>
Quoted 7 lines · Michael Schmitz
Tuomas,
Quoted 1 line
I guess those two bytes have something to do with target (re)selection... There are two different ways of attempting to read these bytes in the code, one is reading them from the FIFO byte by byte, and the other way is to setup a DMA read (write from device). The two different schemes are used in two different functions, and I do not understand why one method would be preferred over the other when comparing these functions.
What the driver attempts to read on reselection are the tag bytes that were used in the previous disconnect. These have to match otherwise we are not reselecting the command we need.
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
Quoted 7 lines
Quoted 3 lines
I think I managed to find these two bytes; They are not ready for DMA, but are sitting in the FIFO waiting to be read. So the loop before the "IRQ2 timeout" is waiting for an interrupt that would tell that the DMA transfer has finished.
The loop checks whether the ESP status indicates the transfer is done
- if the bytes are still stuck in the FIFO I'd guess the DMA does not bother to transfer for such small transfer counts.
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)
explains why the bytes might end up in FIFO; The chip DMA got disabled at some point. Also, you need to explicitly issue a specific (don't know which, yet) command to let the DMA access the FIFO.
Quoted 3 lines
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO after sending the command to the ESP, instead of first setting up the DMA then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to PIO. It is also possible that the chip interrupt is cleared prematurely by reading the interrupt register, in which case the interrupt is not seen by The Loop.
-Tuomas
Hello Tuomas,
Quoted 5 lines
Quoted 3 lines
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
I suppose this is because reconnect_with_tag() cannot rely on the tag information already being in the FIFO when it is called from esp_reconnect(). esp_reconnect() is called from the reselection interrupt so the fifo data is already present.
Quoted 7 lines
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)explains why the bytes might end up in FIFO; The chip DMA got disabled at some point. Also, you need to explicitly issue a specific (don't know which, yet) command to let the DMA access the FIFO.
The chip DMA should be activated by the ESP_CMD_DMA bit that is set in all uses of send_dma_cmd. I can't see where the DMA would have been disabled.
Quoted 9 lines
Quoted 5 lines
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO after sending the command to the ESP, instead of first setting up the DMA then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to PIO. It is also possible that the chip interrupt is cleared prematurely by reading the interrupt register, in which case the interrupt is not seen by The Loop.
That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
Cheers,
Michael
Quoted 53 lines · Tuomas Vainikka
Quoted 11 lines · Michael Schmitz
Tuomas,
Quoted 6 lines
I guess those two bytes have something to do with target (re)selection... There are two different ways of attempting to read these bytes in the code, one is reading them from the FIFO byte by byte, and the other way is to setup a DMA read (write from device). The two different schemes are used in two different functions, and I do not understand why one method would be preferred over the other when comparing these functions.
Quoted 7 lines
What the driver attempts to read on reselection are the tag bytes that were used in the previous disconnect. These have to match otherwise we are not reselecting the command we need.
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
Quoted 10 lines
Quoted 5 lines
I think I managed to find these two bytes; They are not ready for DMA, but are sitting in the FIFO waiting to be read.
So the loop before the "IRQ2 timeout" is waiting for an interrupt that would tell that the DMA transfer has finished.The loop checks whether the ESP status indicates the transfer is done - if the bytes are still stuck in the FIFO I'd guess the DMA does not bother to transfer for such small transfer counts.
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)explains why the bytes might end up in FIFO; The chip DMA got disabled at some point. Also, you need to explicitly issue a specific (don't know which, yet) command to let the DMA access the FIFO.
Quoted 6 lines
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO after sending the command to the ESP, instead of first setting up the DMA then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to PIO. It is also possible that the chip interrupt is cleared prematurely by reading the interrupt register, in which case the interrupt is not seen by The Loop.
-Tuomas
Quoted 31 lines · Michael Schmitz
Hello Tuomas,
Quoted 4 lines
Quoted 3 lines
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
I suppose this is because
reconnect_with_tag()cannot rely on the tag information already being in the FIFO when it is called fromesp_reconnect().esp_reconnect()is called from the reselection interrupt so the fifo data is already present.Quoted 7 lines
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)explains why the bytes might end up in FIFO; The chip DMA got disabled at some point. Also, you need to explicitly issue a specific (don't know which, yet) command to let the DMA access the FIFO.
The chip DMA should be activated by the
ESP_CMD_DMAbit that is set in all uses ofsend_dma_cmd. I can't see where the DMA would have been disabled.Quoted 9 lines
Quoted 5 lines
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO after sending the command to the ESP, instead of first setting up the DMA then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to PIO. It is also possible that the chip interrupt is cleared prematurely by reading the interrupt register, in which case the interrupt is not seen by The Loop.
Quoted 8 lines
That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
This might have nothing to do with the current issue, but during the course of debugging this two byte dma write, I stumbled across this;
[ 2434.370000] ESP: reconnect tag, IRQ(0:10:97), kernel BUG at mm/slab.c:3011! [1]
I had modified the code in esp_scsi.c inside the reconnect_with_tag function to kzalloc the two bytes, single mapping it to "from device" direction in order to check whether the issue was with the dma writing directly to the command block. The dma command was directed to write the two bytes to the area kalloc'd, after which they were copied to the real command block, and the kalloc'd area was unmapped and freed. This would work a couple times when the driver attempted to get the two bytes, but eventually, the above mentioned kernel bug would kick in. I had made sure to unmap and free the two bytes before the function could exit.
Another oddity [2] was that I assigned the kalloc'd bytes to 0xff and 0xfe, and although the code to copy the two bytes to the real command block was after the IRQ2 timeout loop (that continuously calls zorro_esp_irq_pending() ), these values were already sitting in the command block before the loop would exit and the values be copied. I could not prevent this from happening even when I disabled optimizations and/or made the copy through a temporary volatile u8. The last two values from the printk are command_block[0] and command_block[1].
[1] zesp050.cap:836 (printk message in zorro_esp_irq_pending() was disabled)
[2] zesp049.cap:988
-Tuomas
Quoted 35 lines · Michael Schmitz
Hello Tuomas,
Quoted 4 lines
Quoted 3 lines
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
I suppose this is because
reconnect_with_tag()cannot rely on the tag information already being in the FIFO when it is called fromesp_reconnect().esp_reconnect()is called from the reselection interrupt so the fifo data is already present.Quoted 7 lines
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)explains why the bytes might end up in FIFO; The chip DMA got disabled at some point. Also, you need to explicitly issue a specific (don't know which, yet) command to let the DMA access the FIFO.
The chip DMA should be activated by the
ESP_CMD_DMAbit that is set in all uses ofsend_dma_cmd. I can't see where the DMA would have been disabled.Quoted 9 lines
Quoted 5 lines
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO after sending the command to the ESP, instead of first setting up the DMA then sending the command),
I'd rather find out why and where the DMA is disabled before we resort to PIO. It is also possible that the chip interrupt is cleared prematurely by reading the interrupt register, in which case the interrupt is not seen by The Loop.
That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
Quoted 7 lines
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for command block reads and writes, and found out that it didn't fix the problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by esp_scsi.
To cut the long story short, I hardwired TCQ off with a replacement function for esp_slave_configure().
The replacement function resides in zorro_esp.c and is essentially doing the same thing as the original if ESP_DEFAULT_TAGS was set to zero in esp_scsi.h.
There is no need for PIO with the above hack.
I've attached a log of the module loading and some operations on the attached hdd. Note that there are messages such as
[ 4627.040000] sd 0:0:0:0: [sda] Got wrong page and [ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.
which don't seem normal.
-Tuomas
Hello Tuomas,
Quoted 7 lines
Quoted 7 lines
That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
Quoted 6 lines
Quoted 4 lines
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for command block reads and writes, and found out that it didn't fix the
Thanks, that does indeed absolve DMA.
Quoted 4 lines
problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.
I'd have to check with DaveM, but such an assumption might in fact exist.
SCSI-2 features might have been disabled in response to your disk's response in the device configure phase. Maybe someone with a newer SCSI disk (one that does support TCQ from scratch, and the full SCSI-2 command set or better) should try the original driver sometime.
What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or higher? (Apologies for asking this - it will be in one of your old logs but I cannot easily read these here.)
Quoted 7 lines
To cut the long story short, I hardwired TCQ off with a replacement function for
esp_slave_configure().
The replacement function resides inzorro_esp.cand is essentially doing the same thing as the original ifESP_DEFAULT_TAGSwas set to zero inesp_scsi.h.There is no need for PIO with the above hack.
That's a good start - now can anyone remember whether the old Zorro ESP drivers ever used or supported tagged commands? I would not want to hassle DaveM for something that never worked before.
If we can find out how to detect that TCQ is unsupported, Dave could splice that into the core esp_slave_configure() and solve our problem.
Quoted 6 lines
I've attached a log of the module loading and some operations on the attached hdd. Note that there are messages such as
[ 4627.040000] sd 0:0:0:0: [sda] Got wrong page and [ 5106.340000] sda1: WRITE SAME failed. Manually zeroing.
WRITE SAME might be unsupported by your device (guessing, I could not find out where the message originates from). The 'got wrong page' I had to look up, but it also appears to be a case of unsupported feature.
Quoted 1 line
which don't seem normal.
The acid test is - did it destroy your filesystem?
If not, I'd say you did brilliantly.
Thanks again,
Michael
Quoted 79 lines · Tuomas Vainikka
Quoted 45 lines · Michael Schmitz
Hello Tuomas,
Quoted 5 lines
Quoted 3 lines
No idea which functions you refer to regarding PIO (reading from FIFO). Anyway, the DMA will read from the same FIFO that the CPU would, if I understand DMA correctly. There really should be no difference-
esp.scsi.c:1058 versus esp.scsi.c:1120
I suppose this is because
reconnect_with_tag()cannot rely on the tag information already being in the FIFO when it is called fromesp_reconnect().esp_reconnect()is called from the reselection interrupt so the fifo data is already present.Quoted 8 lines
In:
http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXxxsy.pdf
page 42: Enable Selection/Reselection Command (Command Code 44H/C4H)explains why the bytes might end up in FIFO; The chip DMA got disabled at some point. Also, you need to explicitly issue a specific (don't know which,
yet) command to let the DMA access the FIFO.The chip DMA should be activated by the
ESP_CMD_DMAbit that is set in all uses ofsend_dma_cmd. I can't see where the DMA would have been disabled.Quoted 7 lines
Quoted 7 lines
The DMA transfer function can be changed to fetch less than seven bytes from the FIFO by PIO instead of setting up DMA transfer (just poll the FIFO
after sending the command to the ESP, instead of first setting up the DMA
then sending the command),Quoted 6 lines
I'd rather find out why and where the DMA is disabled before we resort to PIO. It is also possible that the chip interrupt is cleared prematurely by
reading the interrupt register, in which case the interrupt is not seen by
The Loop.That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
Quoted 7 lines
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for command block reads and writes, and found out that it didn't fix the problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.To cut the long story short, I hardwired TCQ off with a replacement function for
esp_slave_configure().
The replacement function resides inzorro_esp.cand is essentially doing the same thing as the original ifESP_DEFAULT_TAGSwas set to zero inesp_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
Quoted 17 lines · Michael Schmitz
Hello Tuomas,
Quoted 7 lines
Quoted 7 lines
That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
Quoted 6 lines
Quoted 4 lines
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for command block reads and writes, and found out that it didn't fix the
Thanks, that does indeed absolve DMA.
Quoted 8 lines
Quoted 4 lines
problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.I'd have to check with DaveM, but such an assumption might in fact exist.
SCSI-2 features might have been disabled in response to your disk's response in the device configure phase. Maybe someone with a newer
In fact, the features are never enabled under any circumstance. But, they only seem to add some functionality in how queue tag messages are processed by the chip and not necessarily forbid the functionality if not used.
Quoted 7 lines
SCSI disk (one that does support TCQ from scratch, and the full SCSI-2 command set or better) should try the original driver sometime.
What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or higher? (Apologies for asking this - it will be in one of your old logs but I cannot easily read these here.)
The drive you would find by searching with the model number in the logs would point you to an IDE drive, which is actually connected to a bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI features. I also have a 'real' ST51080N that supports Fast SCSI-2 that I've also tested with the driver to no avail. I will double check again with the real SCSI drive to ascertain that the bridge adapter is not the culprit, just to make sure.
-Tuomas
Quoted 27 lines · Tuomas Vainikka
Quoted 17 lines · Michael Schmitz
Hello Tuomas,
Quoted 7 lines
Quoted 7 lines
That's the attitude - my suggestion was purely pragmatic, in order to overcome that particular roadblock and see whether there's further issues. But fixing this properly would be much preferred.
David Miller is still maintainer of the ESP code - I can't think of anyone better suited to answer ESP specific questions really.
Quoted 6 lines
Quoted 4 lines
Cheers,
Michael
I got it to work. Somehow, at least. I wrote the driver to use PIO for command block reads and writes, and found out that it didn't fix the
Thanks, that does indeed absolve DMA.
Quoted 8 lines
Quoted 4 lines
problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.I'd have to check with DaveM, but such an assumption might in fact exist.
SCSI-2 features might have been disabled in response to your disk's response in the device configure phase. Maybe someone with a newer
In fact, the features are never enabled under any circumstance. But, they only seem to add some functionality in how queue tag messages are processed by the chip and not necessarily forbid the functionality if not used.
Quoted 9 lines
Quoted 7 lines
SCSI disk (one that does support TCQ from scratch, and the full SCSI-2 command set or better) should try the original driver sometime.
What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or higher? (Apologies for asking this - it will be in one of your old logs but I cannot easily read these here.)
The drive you would find by searching with the model number in the logs would point you to an IDE drive, which is actually connected to a bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI features. I also have a 'real' ST51080N that supports Fast SCSI-2 that I've also tested with the driver to no avail. I will double check again with the real SCSI drive to ascertain that the bridge adapter is not the culprit, just to make sure.
The driver without the slave_configure hack fails with the same IRQ2 timeout when the ST51080N hdd is used (see zesp164_orig_slave_cfg.cap).
When the hack is enabled, the hdd works like a charm; none of the aforementioned messages (wrong page, write again) are produced (and the speed is nearly acceptable :-) ) (see zesp165_hacked_slave_cfg.cap).
-Tuomas
Hello Tuomas,
apologies for dropping off the conversation for so long - I only returned from an overseas trip with only sporadic net access three days ago.
Quoted 5 lines
Quoted 4 lines
What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or higher? (Apologies for asking this - it will be in one of your old logs but I cannot easily read these here.)
The drive you would find by searching with the model number in the logs would point you to an IDE drive, which is actually connected to a bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI features. I also have a 'real' ST51080N that supports Fast SCSI-2 that I've also tested with the driver to no avail. I will double check again with the real SCSI drive to ascertain that the bridge adapter is not the culprit, just to make sure.
I'm fully aware the info would have been in the logs, but all I had to work with was a dodgy XP box at my in-law's place, and not a lot of time to poke around.
You have established that the SCSI bridge is responsible for a few odd warnings but nothing serious, so I'd say we give your patched driver a good workout on a number of Amiga m68k porter boxes, Unless you beat me to it, I would suggest I provide a patch against Geert's latest m68k development tree for someone else to integrate into the Debian kernel package (would be a highly experimental one). Does that sound fair?
Cheers,
Michael
Quoted 8 lines · Michael Schmitz
Hello Tuomas,
apologies for dropping off the conversation for so long - I only returned from an overseas trip with only sporadic net access three days ago.
Quoted 4 lines
Quoted 4 lines
What exactly does your device support - SCSI-1, SCSI-2 CCS, SCSI-2 or higher? (Apologies for asking this - it will be in one of your old logs but I cannot easily read these here.)
Quoted 6 lines
Quoted 1 line
The drive you would find by searching with the model number in the logs would point you to an IDE drive, which is actually connected to a bridge adapter (ACard AEC-7720U) that supports full Ultra SCSI features. I also have a 'real' ST51080N that supports Fast SCSI-2 that I've also tested with the driver to no avail. I will double check again with the real SCSI drive to ascertain that the bridge adapter is not the culprit, just to make sure.
I'm fully aware the info would have been in the logs, but all I had to work with was a dodgy XP box at my in-law's place, and not a lot of time to poke around.
You have established that the SCSI bridge is responsible for a few odd warnings but nothing serious, so I'd say we give your patched driver a good workout on a number of Amiga m68k porter boxes, Unless you beat me to it, I would suggest I provide a patch against Geert's latest m68k development tree for someone else to integrate into the Debian kernel package (would be a highly experimental one). Does that sound fair?
Go ahead. I assume you can now open the attachments? If you could just make one small modification; all controllers but Oktagon use a 40 MHz clock. The zorro_esp driver versions I've been spamming to this list all have carried a bad 20 MHz clock setting for the Blizzard 2060 board.
I've actually been able to compile the driver into the kernel and use it for root fs (on my Blizzard 1230-IV).
-Tuomas
Hello Tuomas,
Quoted 3 lines
Quoted 1 line
Go ahead. I assume you can now open the attachments? If you could just make one small modification; all controllers
You bet - though sz compressed .deb packages would still defeat me :-) From here on it's just roadblocks like git rebase as usual.
By rightrs someone with access to the actual hardware should maintain the driver in the long term though.
Quoted 1 line
but Oktagon use a 40 MHz clock. The
zorro_espdriver versions I've been spamming to this list all have carried a bad 20 MHz clock setting for the Blizzard 2060 board.
I'll do that, sure.
Quoted 1 line
I've actually been able to compile the driver into the kernel and use it for root fs (on my Blizzard 1230-IV).
That should count for a successful acid test. Thanks so much for completing and debugging my rather rough draft!
Cheers,
Michael
Quoted 6 lines · Michael Schmitz
Quoted 4 lines
problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.I'd have to check with DaveM, but such an assumption might in fact exist.
BTW, it would be nice to start CCing [email protected] and David S. Miller <[email protected]> on future discussions.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)
Quoted 5 lines · Geert Uytterhoeven
Quoted 4 lines · Michael Schmitz
Quoted 4 lines
problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.
Quoted 9 lines
Quoted 1 line
I'd have to check with DaveM, but such an assumption might in fact exist.
BTW, it would be nice to start CCing [email protected] and David S. Miller <[email protected]> on future discussions.
Gr{oetje,eeting}s,
Geert
Hello,
Does anyone have the register descriptions for the FAS216 chip? It would seem that receiving only one byte during reconnect is perfectly normal [1] unless SCSI-2 features are explicitly enabled (which esp_scsi doesn't seem to be doing).
Also, looking at the timeout formulae in the old NCR53C9x.c driver, the values would be different for FAS216. Why was this dropped from the modern esp_scsi?
1. Page 2 in http://www.datasheetarchive.com/dl/Scans-030/ScansU9X12569.pdf
-Tuomas
Re: esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)
Tuomas,
I might still have a copy of the manual somewhere from way back, if you haven't found it anywhere. Would be on an old disk or even hardcopy in storage, so please confirm you still need it.
Cheers,
Michael
Am 13.09.2013 um 03:36 schrieb Tuomas Vainikka:
Quoted 24 lines · Geert Uytterhoeven
Quoted 5 lines · Michael Schmitz
Quoted 4 lines
Quoted 4 lines
problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by
esp_scsi.Quoted 9 lines
Quoted 1 line
I'd have to check with DaveM, but such an assumption might in fact exist.
BTW, it would be nice to start CCing [email protected] and David S. Miller <[email protected]> on future discussions.
Gr{oetje,eeting}s,
Geert
Hello,
Does anyone have the register descriptions for the FAS216 chip? It would seem that receiving only one byte during reconnect is perfectly normal [1] unless SCSI-2 features are explicitly enabled (which
esp_scsidoesn't seem to be doing).Also, looking at the timeout formulae in the old
NCR53C9x.cdriver, the values would be different for FAS216. Why was this dropped from the modernesp_scsi?1. Page 2 in http://www.datasheetarchive.com/dl/Scans-030/ScansU9X12569.pdf
-Tuomas
Re: esp_scsi QTAG in FAS216
In reply to Tuomas VainikkaFrom: Tuomas Vainikka <[email protected]>
Date: Thu, 12 Sep 2013 18:36:09 +0300
Quoted 4 lines
Does anyone have the register descriptions for the FAS216 chip? It would seem that receiving only one byte during reconnect is perfectly normal [1] unless SCSI-2 features are explicitly enabled (which
esp_scsidoesn't seem to be doing).
This is quite possibly true. I've never see it happen myself while testing the driver though.
Quoted 3 lines
Also, looking at the timeout formulae in the old
NCR53C9x.cdriver, the values would be different for FAS216. Why was this dropped from the modernesp_scsi?
I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver.
I wrote esp_scsi.c based upon the old sparc ESP driver and the docs I had available to me.
Re: esp_scsi QTAG in FAS216
Hello Dave, Tuomas,
Quoted 8 lines
Quoted 3 lines
Also, looking at the timeout formulae in the old
NCR53C9x.cdriver, the values would be different for FAS216. Why was this dropped from the modernesp_scsi?I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver.
I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case.
Can you confirm that, Kars? Any recollection as to the reason?
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
From: Michael Schmitz <[email protected]>
Date: Mon, 7 Apr 2014 08:33:12 +1200
Quoted 11 lines
Hello Dave, Tuomas,
Quoted 8 lines
Quoted 3 lines
Also, looking at the timeout formulae in the old
NCR53C9x.cdriver, the values would be different for FAS216. Why was this dropped from the modernesp_scsi?I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver.
Quoted 5 lines
I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case.
Can you confirm that, Kars? Any recollection as to the reason?
Just as another reference point, I looked at the FreeBSD 'esp' driver and it also uses the 8192 factor for all chips, including FAS216.
Re: esp_scsi QTAG in FAS216
In reply to Michael Schmitz2014-04-06 22:33 GMT+02:00 Michael Schmitz <[email protected]>:
Quoted 12 lines
Hello Dave, Tuomas,
Quoted 8 lines
Quoted 3 lines
Also, looking at the timeout formulae in the old
NCR53C9x.cdriver, the values would be different for FAS216. Why was this dropped from the modernesp_scsi?I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver.
Quoted 5 lines
I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case.
Can you confirm that, Kars? Any recollection as to the reason?
That is the value that's in the data manual of the Symbios Logic SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller).
Funny, according to the QLogic FAS2x6 manual the value should be 7682 for FAS216/216U/236/236U chips...
I don't think it's all that important. It only means that the actual selection timeout used by the chip will be slightly shorter than it is supposed to be.
Kind regards,
Kars.
Re: esp_scsi QTAG in FAS216
Hello Kars,
Quoted 14 lines
Quoted 10 lines
Quoted 4 lines
I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver.I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case.
Can you confirm that, Kars? Any recollection as to the reason?
That is the value that's in the data manual of the Symbios Logic SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller).
Quoted 6 lines
Funny, according to the QLogic FAS2x6 manual the value should be 7682 for FAS216/216U/236/236U chips...
I don't think it's all that important. It only means that the actual selection timeout used by the chip will be slightly shorter than it is supposed to be.
Thanks for checking that - I agree that it might not amount to much.
The more important issue is the one about the one-byte reconnect message. Does the manual speak to that particular issue? Any hint on how we could enable SCSI-2 features on chip init?
Can you point me to a source for the manuals if possible?
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
Hi Michael,
2014-04-11 3:47 GMT+02:00 Michael Schmitz <[email protected]>:
Quoted 3 lines
The more important issue is the one about the one-byte reconnect message. Does the manual speak to that particular issue? Any hint on how we could enable SCSI-2 features on chip init?
There's the SCSI2 bit in the Config 2 register and/or the QTE bit in the Config 3 register. The 53CF9x-2 manual says about SCSI-2 bit:
Bit 2 SCSI-2
Setting this bit allows the FSC to support two new features adopted in
SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2 commands. These features can also be set independently in the Config 3 register.
Tagged-Queueing
When this bit is set and the FSC is selected with ATN (Attention), it will request either one or three message bytes depending on whether ATN remains true or goes false. If ATN is still true after the first byte has been received, the FSC may request two more message bytes before switching to Command phase. If ATN goes false, it will switch to Command phase after the first message byte. When the bit is not set it will request a single message byte (as a target) when selected with ATN, and abort the selection sequence (as an initiator) if the target does not switch to Command phase after one message byte has been transferred.
Group 2 Commands
(seems to only be relevant for target mode).
And about the QTE bit:
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
The message bytes consist of a one-byte identify message and a two-byte queue tag message. The middle byte is the tagged queue message itself and the last byte is the tag value (0 to 255). When this bit is set, the second byte is checked to see if it is a valid queue tagging message. If the value of the byte is not 20, 21 or 22h, the sequence halts and an interrupt is generated. When this bit is not set, the chip aborts the Select With ATN sequence after it receives one Identify Message byte, if ATN is still asserted.
Then there is a section called "Bus Initiated Reselection":
Bus Initiated Reselection
The FSC will allow itself to be reselected as an initiator by a target if it has previously received the Enable Selection/Reselection command. If the sequence completes normally, the following information will be in the FIFO:
* Bus ID
* Identify Message
* Optional 2-byte queue tag message
The bus ID will always be present and will always be one byte. It is an un-encoded version of the state of the bus during Reselection phase.
The identify message will always be present and will always be one byte.
If queue tagging is enabled, and the target is sending a queue tag message, the target will also send two queue tag message bytes.
Quoted 1 line
Can you point me to a source for the manuals if possible?
I only have dead tree versions of the QLogic manual and the Symbios Logic manual.
The only public place I know of is bitsavers, they do have a manual for the 53C94/95/96 online here:
http://bitsavers.trailing-edge.com/pdf/ncr/scsi/NCR_53C94_53C95_53C96_Data_Sheet_Feb90.pdf.
I put the 53C90A/B manual online at
http://members.home.nl/karsdejong/NCR53C90ab.pdf and a preliminary version of the 53CF94/96-2 at
http://members.home.nl/karsdejong/NCR53CF9x-2.pdf.
Kind regards,
Kars.
Re: esp_scsi QTAG in FAS216
Hi Kars,
thanks for the PDFs!
Quoted 7 lines
Bit 2 SCSI-2
Setting this bit allows the FSC to support two new features adopted in
SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2 commands. These features can also be set independently in the Config 3 register.
Quoted 11 lines
Tagged-Queueing
When this bit is set and the FSC is selected with ATN (Attention), it will request either one or three message bytes depending on whether ATN remains true or goes false. If ATN is still true after the first byte has been received, the FSC may request two more message bytes before switching to Command phase. If ATN goes false, it will switch to Command phase after the first message byte. When the bit is not set it will request a single message byte (as a target) when selected with ATN, and abort the selection sequence (as an initiator) if the target does not switch to Command phase after one message byte has been transferred.
That appears to be our problem if I recall correctly Tuomas' debugging report. (reselection, not selection as initiator). As esp_slave_configure() enables queue tags regardless of chip config, we'd best make certain the chip is configured correctly.
The SCSI2 bit is used to test for presence of config register 2 in esp_get_revision but later cleared in the same function. It appears we'd need to set it after the call to scsi_esp_register() - can you test whether that obsoletes the zorro_esp_slave_configure hack, Tuomas?
drivers/scsi/zorro_esp.c +4 -3
@@ -418,9 +418,6 @@ static int zorro_esp_init_one(struct zorro_dev *z,return -EBUSY ; } -/* Fill in the required pieces of hostdata */ - scsi_esp_template.slave_configure = zorro_esp_slave_configure; - host =scsi_host_alloc (tpnt,sizeof (struct esp ));if (!host) {
@@ -508,6 +505,10 @@ static int zorro_esp_init_one(struct zorro_dev *z,if (err) goto fail_free_irq; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ; +zorro_esp_write8 (esp, esp->config2,ESP_CFG2 ); + +zorro_set_drvdata (z, host);return 0 ;
Quoted 10 lines
Group 2 Commands
(seems to only be relevant for target mode).And about the QTE bit:
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your opinion, Dave?
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
From: Michael Schmitz <[email protected]>
Date: Mon, 14 Apr 2014 10:38:09 +1200
Quoted 10 lines
That appears to be our problem if I recall correctly Tuomas' debugging report. (reselection, not selection as initiator). As
esp_slave_configure()enables queue tags regardless of chip config, we'd best make certain the chip is configured correctly.The SCSI2 bit is used to test for presence of config register 2 in
esp_get_revisionbut later cleared in the same function. It appears we'd need to set it after the call toscsi_esp_register()- can you test whether that obsoletes thezorro_esp_slave_configurehack, Tuomas?
...
Quoted 5 lines
Quoted 5 lines
Group 2 Commands
(seems to only be relevant for target mode).And about the QTE bit:
Quoted 8 lines
Quoted 5 lines
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
My preference would be to set this one (named
ESP_CONFIG3_TBMS). Your opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target mode. So it is not relevant for our discussion because this driver is for initiator mode operation only.
But some pieces of documentation seem like they might not agree on this point.
With respect to bit 3 in the config3 register, it can take on one of two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK} it either controls fast SCSI clocking, or it enabled 3 byte message recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB, which enables both features.
Again I looked at the FreeBSD driver and for all chips after plain esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
====================esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection on all esp100a and later chips.
drivers/scsi/esp_scsi.c +1 -3
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)*/ esp->rev =ESP100 ; }else { - esp->config2 =0 ; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ;esp_set_all_config3 (esp,5 ); esp->prev_cfg3 =5 ;esp_write8 (esp->config2,ESP_CFG2 );
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp) }else { esp->rev =ESP236 ; } - esp->config2 =0 ; -esp_write8 (esp->config2,ESP_CFG2 ); } } }
Re: esp_scsi QTAG in FAS216
Quoted 76 lines · David Miller
From: Michael Schmitz <[email protected]>
Date: Mon, 14 Apr 2014 10:38:09 +1200Quoted 10 lines
That appears to be our problem if I recall correctly Tuomas' debugging report. (reselection, not selection as initiator). As
esp_slave_configure()enables queue tags regardless of chip config, we'd best make certain the chip is configured correctly.The SCSI2 bit is used to test for presence of config register 2 in
esp_get_revisionbut later cleared in the same function. It appears we'd need to set it after the call toscsi_esp_register()- can you test whether that obsoletes thezorro_esp_slave_configurehack, Tuomas?...
Quoted 5 lines
Quoted 5 lines
Group 2 Commands
(seems to only be relevant for target mode).And about the QTE bit:
Quoted 7 lines
Quoted 5 lines
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
My preference would be to set this one (named
ESP_CONFIG3_TBMS). Your opinion, Dave?As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register (
ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target mode. So it is not relevant for our discussion because this driver is for initiator mode operation only.But some pieces of documentation seem like they might not agree on this point.
With respect to bit 3 in the config3 register, it can take on one of two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK} it either controls fast SCSI clocking, or it enabled 3 byte message recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_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 <[email protected]>Reported-by Michael Schmitz <[email protected]>Signed-off-by David S. Miller <[email protected]>drivers/scsi/esp_scsi.c +1
-1@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)*/ esp->rev =ESP100 ; }else { - esp->config2 =0 ; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ;esp_set_all_config3 (esp,5 ); esp->prev_cfg3 =5 ;esp_write8 (esp->config2,ESP_CFG2 );
drivers/scsi/esp_scsi.c static void esp_get_revision(struct esp *esp) · line 2192
Quoted 8 lines
drivers/scsi/esp_scsi.c +0
-2@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp) }else { esp->rev =ESP236 ; } - esp->config2 =0 ; -esp_write8 (esp->config2,ESP_CFG2 ); } } }
I'll test these out soon.
Michael, where can I pull the latest version of zorro_esp?
-Tuomas
Re: esp_scsi QTAG in FAS216
Hi Tuomas,
Quoted 64 lines
Quoted 53 lines
Quoted 2 lines
My preference would be to set this one (named
ESP_CONFIG3_TBMS). Your opinion, Dave?As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register (
ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target mode. So it is not relevant for our discussion because this driver is for initiator mode operation only.But some pieces of documentation seem like they might not agree on this point.
With respect to bit 3 in the config3 register, it can take on one of two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK} it either controls fast SCSI clocking, or it enabled 3 byte message recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txtit speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_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 <[email protected]>Reported-by Michael Schmitz <[email protected]>Signed-off-by David S. Miller <[email protected]>drivers/scsi/esp_scsi.c +1
-1@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)*/ esp->rev =ESP100 ; }else { - esp->config2 =0 ; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ;esp_set_all_config3 (esp,5 ); esp->prev_cfg3 =5 ;esp_write8 (esp->config2,ESP_CFG2 );drivers/scsi/esp_scsi.c static void esp_get_revision(struct esp *esp) · line 2192
Quoted 8 lines
drivers/scsi/esp_scsi.c +0
-2@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp) }else { esp->rev =ESP236 ; } - esp->config2 =0 ; -esp_write8 (esp->config2,ESP_CFG2 ); } } }I'll test these out soon.
Quoted 2 lines
Michael, where can I pull the latest version of
zorro_esp?
Not sure my patch had ever made it into Geert's m68k-queue - except for the patch in my previous mail, my zorro_esp.c is still the same as I got from you in October last year. The project has been on the back burner for too long ...
I'll look into setting up pull access to my repository. zorro_esp.c as of today attached for now.
Cheers,
Michael
/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
*
* Copyright (C) 1996 Jesper Skov ([email protected])
*
* Copyright (C) 2011 Michael Schmitz ([email protected]) for
* migration to ESP SCSI core
*/
/*
* ZORRO bus code from:
*/
/*
* Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux.
* Amiga MacroSystemUS WarpEngine SCSI controller.
* Amiga Technologies/DKB A4091 SCSI controller.
*
* Written 1997 by Alan Hourihane <[email protected]>
* plus modifications of the 53c7xx.c driver to support the Amiga. *
* Rewritten to use 53c700.c by Kars de Jong <[email protected]> */
#include <linux/module.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ratelimit.h>
#include <linux/dma-mapping.h>
#include <linux/scatterlist.h>
#include <linux/delay.h>
#include <linux/zorro.h>
#include <linux/slab.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/cacheflush.h>
#include <asm/amigahw.h>
#include <asm/amigaints.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_transport_spi.h>
#include <scsi/scsi_device.h>
#include <scsi/scsi_tcq.h>
#include "esp_scsi.h"
MODULE_AUTHOR("Michael Schmitz <[email protected]>"); MODULE_DESCRIPTION("Amiga Zorro NCR5C9x (ESP) driver"); MODULE_LICENSE("GPL");
#define DMA_WRITE 0x80000000
static struct zorro_driver_data {
const char *name;
unsigned long offset;
unsigned long dma_offset;
int absolute;
int zorro3; /* offset is absolute address */
} zorro_esp_driver_data[] = {
{ .name = "CyberStormI", .offset = 0xf400, .dma_offset = 0xf800, .absolute = 0, .zorro3 = 0 },
{ .name = "CyberStormII", .offset = 0x1ff03, .dma_offset = 0x1ff43, .absolute = 0, .zorro3 = 0 },
{ .name = "Blizzard 2060", .offset = 0x1ff00, .dma_offset = 0x1ffe0, .absolute = 0, .zorro3 = 0 },
{ .name = "Blizzard 1230", .offset = 0x8000, .dma_offset = 0x10000, .absolute = 0, .zorro3 = 0 },
{ .name = "Blizzard 1230II", .offset = 0x10000, .dma_offset = 0x10021, .absolute = 0, .zorro3 = 0 },
{ .name = "Fastlane", .offset = 0x1000001, .dma_offset = 0x1000041, .absolute = 0, .zorro3 = 1 },
{ 0 }
};static struct zorro_device_id zorro_esp_zorro_tbl[] = {
{
.id = ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM,
.driver_data = (unsigned long)&zorro_esp_driver_data[0],
},
{
.id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
.driver_data = (unsigned long)&zorro_esp_driver_data[0],
},
{
.id = ZORRO_PROD_PHASE5_CYBERSTORM_MK_II,
.driver_data = (unsigned long)&zorro_esp_driver_data[1],
},
{
.id = ZORRO_PROD_PHASE5_BLIZZARD_2060,
.driver_data = (unsigned long)&zorro_esp_driver_data[2],
},
{
.id = ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260,
.driver_data = (unsigned long)&zorro_esp_driver_data[3],
},
{
.id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
.driver_data = (unsigned long)&zorro_esp_driver_data[4],
},
{ 0 }
};MODULE_DEVICE_TABLE(zorro, zorro_esp_zorro_tbl);
struct blz1230_dma_registers {
volatile unsigned char dma_addr; /* DMA address [0x0000] */
unsigned char dmapad2[0x7fff];
volatile unsigned char dma_latch; /* DMA latch [0x8000] */
};struct blz2060_dma_registers {
volatile unsigned char dma_led_ctrl; /* DMA led control [0x000] */
unsigned char dmapad1[0x0f];
volatile unsigned char dma_addr0; /* DMA address (MSB) [0x010] */
unsigned char dmapad2[0x03];
volatile unsigned char dma_addr1; /* DMA address [0x014] */
unsigned char dmapad3[0x03];
volatile unsigned char dma_addr2; /* DMA address [0x018] */
unsigned char dmapad4[0x03];
volatile unsigned char dma_addr3; /* DMA address (LSB) [0x01c] */
};/* DMA control bits */
#define BLZ2060_DMA_LED 0x02 /* HD led control 1 = off */
/*
* m68k always assumes readl/writel operate on little endian
* mmio space; this is wrong at least for Sun3x, so we
* need to workaround this until a proper way is found */
#if 0
#define dma_read32(REG) \
readl(esp->dma_regs + (REG))
#define dma_write32(VAL, REG) \
writel((VAL), esp->dma_regs + (REG))
#else
#define dma_read32(REG) \
*(volatile u32 *)(esp->dma_regs + (REG))
#define dma_write32(VAL, REG) \
do { *(volatile u32 *)(esp->dma_regs + (REG)) = (VAL); } while (0)#endif
/*
* On all implementations except for the Oktagon, padding between ESP
* registers is three bytes.
* On Oktagon, it is one byte - use a different accessor there. *
* Oktagon currently unsupported!
*/
static void zorro_esp_write8(struct esp *esp, u8 val, unsigned long reg)
{
writeb(val, esp->regs + (reg * 4UL));
}static u8 zorro_esp_read8(struct esp *esp, unsigned long reg)
{
return readb(esp->regs + (reg * 4UL));
}static dma_addr_t zorro_esp_map_single(struct esp *esp, void *buf,
size_t sz, int dir)
{
return dma_map_single(esp->dev, buf, sz, dir);
}static int zorro_esp_map_sg(struct esp *esp, struct scatterlist *sg,
int num_sg, int dir)
{
return dma_map_sg(esp->dev, sg, num_sg, dir);
}static void zorro_esp_unmap_single(struct esp *esp, dma_addr_t addr,
size_t sz, int dir)
{
dma_unmap_single(esp->dev, addr, sz, dir);
}static void zorro_esp_unmap_sg(struct esp *esp, struct scatterlist *sg,
int num_sg, int dir)
{
dma_unmap_sg(esp->dev, sg, num_sg, dir);
}static int zorro_esp_irq_pending(struct esp *esp)
{
/* check ESP status register; DMA has no status reg. */
if ( zorro_esp_read8(esp,ESP_STATUS) & ESP_STAT_INTR )
return 1;
return 0;
}static void zorro_esp_reset_dma(struct esp *esp)
{
/* nothing to do here */
}static void zorro_esp_dma_drain(struct esp *esp)
{
/* nothing to do here */
}static void zorro_esp_dma_invalidate(struct esp *esp)
{
/* nothing to do here */
}#ifdef ZORRO_ESP_PIO_CMD
static void zorro_esp_send_pio_cmd(struct esp *esp, u32 esp_count,
int write, u8 cmd)
{
/*
NOTE that this function is only for esp->command_block!
*/
u32 i, j;
u32 fbytes = 0;
if (esp_count > 16) {
printk( "zorro_esp: PIO: Too many bytes for command block transfer!\n" );
return;
}
cmd &= ~(ESP_CMD_DMA);
if (write) {
scsi_esp_cmd(esp, cmd);
j = 0;
while (1) {
i = 0;
fbytes = 0;
while (!fbytes) {
fbytes = zorro_esp_read8(esp, ESP_FFLAGS) & ESP_FF_FBYTES;
i++;
if ( i > 1000000 ) break;
udelay(1);
}
if (!fbytes) break;
while (fbytes) {
esp->command_block[j++] = zorro_esp_read8(esp, ESP_FDATA);
fbytes--;
}
if ( j == esp_count ) break;
i = 0;
while (!zorro_esp_irq_pending(esp)) {
i++;
if ( i > 1000000 ) break;
udelay(1);
}
if ( i > 1000000 ) {
printk( "zorro_esp: PIO: IRQ TIMEOUT!\n" );
break;
}
scsi_esp_cmd(esp, ESP_CMD_TI);
}
} else {
scsi_esp_cmd(esp, ESP_CMD_FLUSH);
fbytes = esp_count;
for (i=0;i<fbytes;i++) zorro_esp_write8(esp, esp->command_block[i], ESP_FDATA);
scsi_esp_cmd(esp, cmd);
}
if ( j != esp_count )
printk( "zorro_esp: PIO: %d bytes transferred out of %d expected.\n" );}
#endif /* ZORRO_ESP_PIO_CMD */
// Blizzard 1230/60 SCSI-IV DMA
static void zorro_esp_send_blz1230_dma_cmd(struct esp *esp, u32 addr,
u32 esp_count, u32 dma_count, int write, u8 cmd)
{
struct blz1230_dma_registers *dregs = (struct blz1230_dma_registers *) (esp->dma_regs);#ifdef ZORRO_ESP_PIO_CMD
if (addr == esp->command_block_dma) {
zorro_esp_send_pio_cmd(esp, esp_count, write, cmd);
return;
}
#endif
BUG_ON(!(cmd & ESP_CMD_DMA));
if (write)
cache_clear(addr, esp_count);
else
cache_push(addr, esp_count);
addr >>= 1;
if (write)
addr &= ~(DMA_WRITE);
else
addr |= DMA_WRITE;
dregs->dma_latch = (addr >> 24) & 0xff;
dregs->dma_addr = (addr >> 24) & 0xff;
dregs->dma_addr = (addr >> 16) & 0xff;
dregs->dma_addr = (addr >> 8) & 0xff;
dregs->dma_addr = (addr ) & 0xff;
scsi_esp_cmd(esp, ESP_CMD_DMA);
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);// zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
scsi_esp_cmd(esp, cmd); }
// Blizzard 2060 DMA
static void zorro_esp_send_blz2060_dma_cmd(struct esp *esp, u32 addr,
u32 esp_count, u32 dma_count, int write, u8 cmd)
{
struct blz2060_dma_registers *dregs = (struct blz2060_dma_registers *) (esp->dma_regs);#ifdef ZORRO_ESP_PIO_CMD
if (addr == esp->command_block_dma) {
zorro_esp_send_pio_cmd(esp, esp_count, write, cmd);
return;
}
#endif
BUG_ON(!(cmd & ESP_CMD_DMA));
if (write)
cache_clear(addr, esp_count);
else
cache_push(addr, esp_count);
addr >>= 1;
if (write)
addr &= ~(DMA_WRITE);
else
addr |= DMA_WRITE;
dregs->dma_addr3 = (addr ) & 0xff;
dregs->dma_addr2 = (addr >> 8) & 0xff;
dregs->dma_addr1 = (addr >> 16) & 0xff;
dregs->dma_addr0 = (addr >> 24) & 0xff;
scsi_esp_cmd(esp, ESP_CMD_DMA);
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);// zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
scsi_esp_cmd(esp, cmd); }
static int zorro_esp_dma_error(struct esp *esp)
{
/* nothing to do here - there seems to be no way to check for DMA errors */
return 0;
}static struct esp_driver_ops zorro_esp_ops = {
.esp_write8 = zorro_esp_write8,
.esp_read8 = zorro_esp_read8,
.map_single = zorro_esp_map_single,
.map_sg = zorro_esp_map_sg,
.unmap_single = zorro_esp_unmap_single,
.unmap_sg = zorro_esp_unmap_sg,
.irq_pending = zorro_esp_irq_pending,
.reset_dma = zorro_esp_reset_dma,
.dma_drain = zorro_esp_dma_drain,
.dma_invalidate = zorro_esp_dma_invalidate,
.send_dma_cmd = zorro_esp_send_blz2060_dma_cmd,
.dma_error = zorro_esp_dma_error,
};static int zorro_esp_slave_configure(struct scsi_device *dev)
{
/*
This function is used instead of the original
esp_scsi.c: esp_slave_configure() to hardwire
TCQ off until someone finds out where things
go wrong.
*/
struct esp *esp = shost_priv(dev->host);
struct esp_target_data *tp = &esp->target[dev->id];
scsi_deactivate_tcq(dev, dev->host->cmd_per_lun);
tp->flags |= ESP_TGT_DISCONNECT;
if (!spi_initial_dv(dev->sdev_target))
spi_dv_device(dev);
return 0;
}static int zorro_esp_init_one(struct zorro_dev *z,
const struct zorro_device_id *ent)
{
struct scsi_host_template *tpnt = &scsi_esp_template;
struct Scsi_Host *host;
struct esp *esp;
struct zorro_driver_data *zdd;
unsigned long board, ioaddr, dmaaddr;
int err = -ENOMEM;
board = zorro_resource_start(z);
zdd = (struct zorro_driver_data *)ent->driver_data;
printk( "zorro_esp: %s found at address 0x%lx.\n", zdd->name, board );
if (zdd->absolute) {
ioaddr = zdd->offset;
dmaaddr = zdd->dma_offset;
} else {
ioaddr = board + zdd->offset;
dmaaddr = board + zdd->dma_offset;
}
if (!zorro_request_device(z, zdd->name)) {
printk(KERN_ERR "zorro_esp: cannot reserve region 0x%lx, abort\n",
board);
return -EBUSY;
}
host = scsi_host_alloc(tpnt, sizeof(struct esp));
if (!host) {
printk(KERN_ERR "zorro_esp: No host detected; "
"board configuration problem?\n");
goto out_free;
}
host->base = ioaddr;
host->this_id = 7;
esp = shost_priv(host);
esp->host = host;
esp->dev = &z->dev;
esp->scsi_id = host->this_id;
esp->scsi_id_mask = (1 << esp->scsi_id);
/* Switch to the correct the DMA routine and clock frequency. */
switch ( ent->id ) {
case ZORRO_PROD_PHASE5_BLIZZARD_2060: {
zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz2060_dma_cmd;
esp->cfreq = 40000000;
break;
}
case ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260: {
zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz1230_dma_cmd;
esp->cfreq = 40000000;
break;
}
default: {
/* Oh noes */
printk(KERN_ERR "zorro_esp: Unsupported board!\n");
goto fail_free_host;
break;
}
}
esp->ops = &zorro_esp_ops;
if (ioaddr > 0xffffff)
esp->regs = ioremap_nocache(ioaddr, 0x20);
else
esp->regs = (void __iomem *)ZTWO_VADDR(ioaddr);
if (!esp->regs)
goto fail_free_host;
/* Let's check whether a Blizzard 12x0 really has SCSI */
if ((ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260) ||
(ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060)) {
zorro_esp_write8(esp, (ESP_CONFIG1_PENABLE | 7), ESP_CFG1);
if ( zorro_esp_read8(esp, ESP_CFG1) != (ESP_CONFIG1_PENABLE | 7) )
goto fail_free_host;
}
if (ioaddr > 0xffffff) {
// I guess the Fastlane Z3 will be the only one to catch this?
// Here's a placeholder for now...
if ( ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260 )
esp->dma_regs = ioremap_nocache( dmaaddr, sizeof(struct blz1230_dma_registers) );
} else
esp->dma_regs = (void __iomem *)ZTWO_VADDR(dmaaddr);
if (!esp->dma_regs)
goto fail_unmap_regs;
esp->command_block = dma_alloc_coherent(esp->dev, 16,
&esp->command_block_dma,
GFP_KERNEL);
if (!esp->command_block)
goto fail_unmap_dma_regs;
host->irq = IRQ_AMIGA_PORTS;
err = request_irq(host->irq, scsi_esp_intr, IRQF_SHARED,
"Amiga Zorro ESP", esp);
if (err < 0)
goto fail_free_command_block;// esp->flags = ESP_FLAG_DISABLE_SYNC;
/* register the chip */ err = scsi_esp_register(esp, &z->dev); if (err) goto fail_free_irq; esp->config2 = ESP_CONFIG2_SCSI2ENAB; zorro_esp_write8(esp, esp->config2, ESP_CFG2); zorro_set_drvdata(z, host); return 0;
fail_free_irq:
free_irq(host->irq, esp);
fail_free_command_block:
dma_free_coherent(esp->dev, 16, esp->command_block, esp->command_block_dma);
fail_unmap_dma_regs:
if (ioaddr > 0xffffff) iounmap(esp->dma_regs);
fail_unmap_regs:
if (ioaddr > 0xffffff) iounmap(esp->regs);
fail_free_host:
scsi_host_put(host);
out_free:
zorro_release_device(z); return -ENODEV; }
static void zorro_esp_remove_one(struct zorro_dev *z)
{
struct Scsi_Host *host = zorro_get_drvdata(z);
struct esp *esp = shost_priv(host);
scsi_esp_unregister(esp);
/* Disable interrupts. Perhaps use disable_irq instead ... */
free_irq(host->irq, esp);
dma_free_coherent(esp->dev, 16,
esp->command_block,
esp->command_block_dma);
if ( host->base > 0xffffff ) {
iounmap(esp->dma_regs);
iounmap(esp->regs);
}
scsi_host_put(host);
zorro_release_device(z);
}static struct zorro_driver zorro_esp_driver = {
.name = "zorro_esp-scsi",
.id_table = zorro_esp_zorro_tbl,
.probe = zorro_esp_init_one,
.remove = zorro_esp_remove_one,
};
static int __init zorro_esp_scsi_init(void)
{
return zorro_register_driver(&zorro_esp_driver);
}static void __exit zorro_esp_scsi_exit(void)
{
zorro_unregister_driver(&zorro_esp_driver);
}module_init(zorro_esp_scsi_init);module_exit(zorro_esp_scsi_exit);
Re: esp_scsi QTAG in FAS216
Hi Michael,
[sorry for the long delay]
Quoted 4 lines · Michael Schmitz
Not sure my patch had ever made it into Geert's m68k-queue - except for the patch in my previous mail, my
zorro_esp.cis still the same as I got from you in October last year. The project has been on the back burner for too long ...
I don't think it makes much sense to add it to my queue, as it's purely SCSI and not critical for current m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: esp_scsi QTAG in FAS216
Hi Geert,
Quoted 1 line
[sorry for the long delay]
Tell me about it :-) I haven't had a good idea how to address this problem so rather kept mum about it.
Quoted 8 lines · Michael Schmitz
Quoted 4 lines
Not sure my patch had ever made it into Geert's m68k-queue - except for the patch in my previous mail, my
zorro_esp.cis still the same as I got from you in October last year. The project has been on the back burner for too long ...I don't think it makes much sense to add it to my queue, as it's purely SCSI and not critical for current m68k.
Fine, Ill try and resolve that with Dave then. Tuomas will need to do the testing (unless someone wants to drop off the necessary hardware with me - unlikely).
Thanks,
Michael
Re: esp_scsi QTAG in FAS216
In reply to David MillerHi Dave,
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
My preference would be to set this one (named
ESP_CONFIG3_TBMS). Your opinion, Dave?As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register (
ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target mode. So it is not relevant for our discussion because this driver is for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have unintended side effects. It's just easier to test whether this fixes our problem.
Quoted 9 lines
But some pieces of documentation seem like they might not agree on this point.
With respect to bit 3 in the config3 register, it can take on one of two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK} it either controls fast SCSI clocking, or it enabled 3 byte message recognition.
Quoted 8 lines
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txtit speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_CONFIG2_SCSI2ENAB, which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the Amiga driver cases, it will always be the 3 byte message feature controlled by that bit, as far as I can see.
Quoted 5 lines
Again I looked at the FreeBSD driver and for all chips after plain esp100, they set
ESP_CONFIG2_SCSI2ENAB.Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro driver, thanks,
Michael
Quoted 33 lines
====================
esp_scsi: Set SCSI2 bit in config2 register.This should allow proper recognition of 3 byte reselection on all esp100a and later chips.
Reported-by Kars de Jong <[email protected]>Reported-by Michael Schmitz <[email protected]>Signed-off-by David S. Miller <[email protected]>drivers/scsi/esp_scsi.c +1
-3@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)*/ esp->rev =ESP100 ; }else { - esp->config2 =0 ; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ;esp_set_all_config3 (esp,5 ); esp->prev_cfg3 =5 ;esp_write8 (esp->config2,ESP_CFG2 );@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp) }else { esp->rev =ESP236 ; } - esp->config2 =0 ; -esp_write8 (esp->config2,ESP_CFG2 ); } } }
Re: esp_scsi QTAG in FAS216
Quoted 72 lines · Michael Schmitz
Hi Dave,
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
My preference would be to set this one (named
ESP_CONFIG3_TBMS). Your opinion, Dave?As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register (
ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target mode. So it is not relevant for our discussion because this driver is for initiator mode operation only.Agreed.
ESP_CONFIG2_SCSI2ENABmight do more than we intend, and have unintended side effects. It's just easier to test whether this fixes our problem.Quoted 9 lines
But some pieces of documentation seem like they might not agree on this point.
With respect to bit 3 in the config3 register, it can take on one of two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK} it either controls fast SCSI clocking, or it enabled 3 byte message recognition.
Quoted 8 lines
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_CONFIG2_SCSI2ENAB, which enables both features.That's what I understood from the bits Kars quoted, yes. And in the Amiga driver cases, it will always be the 3 byte message feature controlled by that bit, as far as I can see.
Quoted 5 lines
Again I looked at the FreeBSD driver and for all chips after plain esp100, they set
ESP_CONFIG2_SCSI2ENAB.Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro driver, thanks,
Michael
Quoted 25 lines
====================
esp_scsi: Set SCSI2 bit in config2 register.This should allow proper recognition of 3 byte reselection on all esp100a and later chips.
Reported-by Kars de Jong <[email protected]>Reported-by Michael Schmitz <[email protected]>Signed-off-by David S. Miller <[email protected]>drivers/scsi/esp_scsi.c +1
-1@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)*/ esp->rev =ESP100 ; }else { - esp->config2 =0 ; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ;esp_set_all_config3 (esp,5 ); esp->prev_cfg3 =5 ;esp_write8 (esp->config2,ESP_CFG2 );@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
Quoted 9 lines
drivers/scsi/esp_scsi.c static void esp_get_revision(struct esp *esp) · line 2192
Quoted 8 lines
drivers/scsi/esp_scsi.c +0
-2}else { esp->rev =ESP236 ; } - esp->config2 =0 ; -esp_write8 (esp->config2,ESP_CFG2 ); } } }
Hello,
The patch above doesn't work. I've attached a log. Looks like the same problem we've had all along. The gzipped logs have all esp_scsi debug messages enabled for a non-patched and patched versions.
-Tuomas
modprobe zorro_espzorro_esp: Blizzard 1230 found at address 0xea0000.
esp: esp0, regs[80ea8000:80eb0000] irq[2]
esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
scsi 0:0:2:0: Direct-Access SEAGATE ST51080N 0913 PQ: 0 ANSI: 2
scsi target0:0:2: Beginning Domain Validation
scsi target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
scsi target0:0:2: Domain Validation skipping write tests
scsi target0:0:2: Ending Domain Validation
sd 0:0:2:0: [sda] 2109840 512-byte logical blocks: (1.08 GB/1.00 GiB)
sd 0:0:2:0: [sda] Write Protect is off
sd 0:0:2:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:2:0: Attached scsi generic sg0 type 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
Dev sda: unable to read RDB block 0
sda: unable to read partition table
sd 0:0:2:0: [sda] Attached SCSI disk
root@amiga:~# esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 00 00 00 08 00 end_request: I/O error, dev sda, sector 2109696 Buffer I/O error on device sda, logical block 263712 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 00 00 00 08 00 end_request: I/O error, dev sda, sector 2109696 Buffer I/O error on device sda, logical block 263712 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 80 00 00 08 00 end_request: I/O error, dev sda, sector 2109824 Buffer I/O error on device sda, logical block 263728 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 80 00 00 08 00 end_request: I/O error, dev sda, sector 2109824 Buffer I/O error on device sda, logical block 263728 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 end_request: I/O error, dev sda, sector 8 Buffer I/O error on device sda, logical block 1 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 end_request: I/O error, dev sda, sector 2109832 Buffer I/O error on device sda, logical block 263729 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 50 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 80 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 20 31 88 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 08 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 blk_update_request: 24 callbacks suppressed end_request: I/O error, dev sda, sector 0 quiet_error: 24 callbacks suppressed Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 78 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 78 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 78 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 78 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 78 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 78 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 10 00 00 08 00 blk_update_request: 32 callbacks suppressed end_request: I/O error, dev sda, sector 16 quiet_error: 32 callbacks suppressed Buffer I/O error on device sda, logical block 2 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 end_request: I/O error, dev sda, sector 128 Buffer I/O error on device sda, logical block 16 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 end_request: I/O error, dev sda, sector 128 Buffer I/O error on device sda, logical block 16 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 end_request: I/O error, dev sda, sector 128 Buffer I/O error on device sda, logical block 16 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 10 00 00 08 00 end_request: I/O error, dev sda, sector 16 Buffer I/O error on device sda, logical block 2 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 end_request: I/O error, dev sda, sector 128 Buffer I/O error on device sda, logical block 16 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 end_request: I/O error, dev sda, sector 64 Buffer I/O error on device sda, logical block 8 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 end_request: I/O error, dev sda, sector 64 Buffer I/O error on device sda, logical block 8 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 end_request: I/O error, dev sda, sector 64 Buffer I/O error on device sda, logical block 8 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 end_request: I/O error, dev sda, sector 64 Buffer I/O error on device sda, logical block 8 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 40 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 01 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 10 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 10 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 10 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 blk_update_request: 32 callbacks suppressed end_request: I/O error, dev sda, sector 0 quiet_error: 32 callbacks suppressed Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 end_request: I/O error, dev sda, sector 8 Buffer I/O error on device sda, logical block 1 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 80 00 00 08 00 end_request: I/O error, dev sda, sector 128 Buffer I/O error on device sda, logical block 16 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 10 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 18 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 38 00 00 08 00 esp: esp0: Reconnect IRQ2 timeout sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:2:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
root@amiga:~# lsmod Module Size Used by sg 19108 0 zorro_esp 3338 0 esp_scsi 21298 1 zorro_esp nfsd 67490 0 ipv6 229989 24 evdev 8390 0 root@amiga:~#
Re: esp_scsi QTAG in FAS216
In reply to David MillerQuoted 19 lines · David Miller
Quoted 4 lines
esp_get_revisionbut later cleared in the same function. It appears we'd need to set it after the call toscsi_esp_register()- can you test whether that obsoletes thezorro_esp_slave_configurehack, Tuomas?...
Quoted 5 lines
Quoted 5 lines
Group 2 Commands
(seems to only be relevant for target mode).And about the QTE bit:
Quoted 8 lines
Quoted 5 lines
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register.
My preference would be to set this one (named
ESP_CONFIG3_TBMS). Your opinion, Dave?
Quoted 7 lines
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register (
ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target mode. So it is not relevant for our discussion because this driver is for initiator mode operation only.But some pieces of documentation seem like they might not agree on this point.
I think there is ambiguity, and I see some differences between the documentation for ESP236 and that for FAS236 devices. But I don't agree that ESP_CONFIG2_SCSI2ENAB is only for target mode.
This bug affects re-selection. So documentation which refers to a "device [being] selected" tends to be ambiguous, because re-selection is still selection in some sense. E.g. the Am53C94/Am53C96 (preliminary) datasheet says this:
Extended Message Feature: When the S2FE [ESP_CONFIG2_SCSI2ENAB] bit is set and the device is selected with attention, the device will monitor the /ATN signal at the end of the first message byte. If the /ATN signal is active, the device will request two more message bytes before switching to the command phase. If the /ATN signal is inactive the device will switch to the command phase.
But the next part is clear enough and seems to explain the mac_esp (ESP236) failure:
When the S2FE bit is reset the device as a target will request a single message byte. As an initiator, the device will abort the selection sequence if the target does not switch to the command phase after receiving a single message byte.
The document you cited, NCR53C9X.txt, seems unambiguous about the role of the initiator. (Just search for "identify message" to see the relevant parts.)
Moreover, for reselection, NCR53C9X.txt says the chip will expect 2 tag bytes only when tagged queueing is enabled, that is, QTE bit aka ESP_CONFIG3_TMS bit is set. The QTE feature "is also enabled by setting bit 3 in the Configuration 2 register", aka ESP_CONFIG2_SCSI2ENAB, which is what your patch does.
Quoted 6 lines
With respect to bit 3 in the config3 register, it can take on one of two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK} it either controls fast SCSI clocking, or it enabled 3 byte message recognition.
Quoted 7 lines
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_CONFIG2_SCSI2ENAB, which enables both features.
Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only problem is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, when the CONFIG3 register is written to?
Quoted 5 lines
Again I looked at the FreeBSD driver and for all chips after plain esp100, they set
ESP_CONFIG2_SCSI2ENAB.Can we try testing the following patch?
It could be that this patch would be sufficient to fix mac_esp because ESP236 seems to have no ESP_CONFIG3_TMS bit.
We know that this patch didn't work for zorro_esp (FAS236) but it would be helpful to know what value the CONFIG3 register took in the end.
Quoted 33 lines
====================
esp_scsi: Set SCSI2 bit in config2 register.This should allow proper recognition of 3 byte reselection on all esp100a and later chips.
Reported-by Kars de Jong <[email protected]>Reported-by Michael Schmitz <[email protected]>Signed-off-by David S. Miller <[email protected]>drivers/scsi/esp_scsi.c +1
-3@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)*/ esp->rev =ESP100 ; }else { - esp->config2 =0 ; + esp->config2 =ESP_CONFIG2_SCSI2ENAB ;esp_set_all_config3 (esp,5 ); esp->prev_cfg3 =5 ;esp_write8 (esp->config2,ESP_CFG2 );@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp) }else { esp->rev =ESP236 ; } - esp->config2 =0 ; -esp_write8 (esp->config2,ESP_CFG2 ); } } }
Re: esp_scsi QTAG in FAS216
Quoted 8 lines · On Sat, 29 Oct 2016, I wrote:
Quoted 5 lines · David Miller
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
Quoted 8 lines
Quoted 3 lines
it speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_CONFIG2_SCSI2ENAB, which enables both features.Yes, so setting the
ESP_CONFIG2_SCSI2ENABbit is correct. The only problem is, doesn't theESP_CONFIG3_TMSbit get cleared again later, when the CONFIG3 register is written to?
Nevermind my question. To falsify my own theory, I see that ESP_CONFIG3_TMS == ESP_CONFIG3_FCLK, and thus esp_scsi does actually set the relevant bit, and therefore "the FSC can receive 3-byte messages during businitiated select with ATN."
Re: esp_scsi QTAG in FAS216
Hi Finn,
Am 30.10.2016 um 15:33 schrieb Finn Thain:
Quoted 20 lines · On Sat, 29 Oct 2016, I wrote:
Quoted 9 lines · David Miller
Quoted 6 lines
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
Quoted 8 lines
Quoted 3 lines
it speaks as if
ESP_CONFIG3_TMSandESP_CONFIG3_TENBare merely finer grained versions of config2 register settingESP_CONFIG2_SCSI2ENAB, which enables both features.Yes, so setting the
ESP_CONFIG2_SCSI2ENABbit is correct. The only problem is, doesn't theESP_CONFIG3_TMSbit get cleared again later, when the CONFIG3 register is written to?
Quoted 6 lines
Nevermind my question. To falsify my own theory, I see that
ESP_CONFIG3_TMS==ESP_CONFIG3_FCLK, and thusesp_scsidoes actually set the relevant bit, and therefore "the FSC can receive 3-byte messages during businitiated select with ATN."From my reading of the quoted docs,ESP_CONFIG3_TMS is valid for FAS100A
(and later?). What esp_scsi sets (for FAS236 chips) is fast SCSI clock mode. The relevant bit for three byte message support for Mac and Amiga ESP hardware should be ESP_CONFIG3_TENB.
I had tried to set that bit in zorro_esp_slave_configure but had not done a proper job of it - I'd only set esp->config3 and forgot to set tp->esp_config3. Time to retest this ...
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
Hi Finn,
Quoted 3 lines
I had tried to set that bit in
zorro_esp_slave_configurebut had not done a proper job of it - I'd only setesp->config3and forgot to settp->esp_config3. Time to retest this ...
I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to be set for all targets if at least one SCSI-2 target is on the bus and we allow dosconnecting, no?
Adrian - any chance I can get access to elgar again for some more testing?
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
Quoted 7 lines · Michael Schmitz
Quoted 3 lines
I had tried to set that bit in
zorro_esp_slave_configurebut had not done a proper job of it - I'd only setesp->config3and forgot to settp->esp_config3. Time to retest this ...I don't think it's quite that easy - the
ESP_CONFIG3_TENBbit needs to be set for all targets if at least one SCSI-2 target is on the bus and we allow dosconnecting, no?
I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit.
The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS == ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash.
Quoted 6 lines
Adrian - any chance I can get access to elgar again for some more testing?
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
Hi Finn,
Am 01.11.2016 um 12:47 schrieb Finn Thain:
Quoted 7 lines · Michael Schmitz
Quoted 5 lines
Quoted 4 lines
I had tried to set that bit in
zorro_esp_slave_configurebut had not done a proper job of it - I'd only setesp->config3and forgot to settp->esp_config3. Time to retest this ...
Quoted 6 lines
Quoted 3 lines
I don't think it's quite that easy - the
ESP_CONFIG3_TENBbit needs to be set for all targets if at least one SCSI-2 target is on the bus and we allow dosconnecting, no?I think
ESP_CONFIG3_TENBis for FAS100A and FASHME. The bug here is on ESP236 and FAS236, soESP_CONFIG3_TBMSwould be the relevant bit.
I stand corrected. Err... confused.
When setting ESP_CONFIG3_TBMS, should we set ESP_CONFIG3_GTM as well?
Quoted 3 lines
The bit gets set when
ESP_CONFIG2_SCSI2ENABgets set (as in David's patch) so we then need to avoid clobbering it, sinceESP_CONFIG3_TBMS==ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash.
I'd want to set these bits for ESP236 and FAS236 only, so no clash with HME. As you found out, ESP_CONFIG3_TBMS aka ESP_CONFIG3_EWIDE gets clobbered on bus reset cleanup unconditionally.
Cheers,
Michael
Re: esp_scsi QTAG in FAS216
Quoted 14 lines · Michael Schmitz
Hi Finn,
Am 01.11.2016 um 12:47 schrieb Finn Thain:
Quoted 11 lines · Michael Schmitz
Quoted 8 lines
Quoted 4 lines
I had tried to set that bit in
zorro_esp_slave_configurebut had not done a proper job of it - I'd only setesp->config3and forgot to settp->esp_config3. Time to retest this ...I don't think it's quite that easy - the
ESP_CONFIG3_TENBbit needs to be set for all targets if at least one SCSI-2 target is on the bus and we allow dosconnecting, no?
Quoted 6 lines
Quoted 2 lines
I think
ESP_CONFIG3_TENBis for FAS100A and FASHME. The bug here is on ESP236 and FAS236, soESP_CONFIG3_TBMSwould be the relevant bit.I stand corrected. Err... confused.
When setting
ESP_CONFIG3_TBMS, should we setESP_CONFIG3_GTMas well?
I think that depends entirely on the target. But it isn't relevant to the bug at hand AFAICS.
Quoted 19 lines
Quoted 5 lines
The bit gets set when
ESP_CONFIG2_SCSI2ENABgets set (as in David's patch) so we then need to avoid clobbering it, sinceESP_CONFIG3_TBMS==ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash.I'd want to set these bits for ESP236 and FAS236 only, so no clash with HME. As you found out,
ESP_CONFIG3_TBMSakaESP_CONFIG3_EWIDEgets clobbered on bus reset cleanup unconditionally.Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 48 lines · Michael Schmitz
Geert,
Quoted 12 lines · Michael Schmitz
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 301.880000] esp: esp0: Reconnect IRQ2 timeoutBeware that this message (incl. the number) is hardcoded in
drivers/scsi/esp_scsi.c:if (i == ESP_RESELECT_TAG_LIMIT) { printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n", esp->host->unique_id); return NULL; }Quoted 3 lines
The driver prints "IRQ1" or "IRQ2".
Fortunately,
IRQ_AMIGA_PORTSis 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_blockandcommand_block_dmaaddresses - does the DMA require virtual or physical addresses?Quoted 27 lines
Quoted 26 lines
Quoted 18 lines
Quoted 3 lines
Are there interrupts logged for IRQ2 at all (cat
/proc/interrupts)? It looks to me as though all DMA transfers fail (the first command to fail isREAD_CAPACITYwhich would usually be issued right after IDENTIFY IIRC).root@amiga:/# cat /proc/interrupts CPU0 2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP 6: 456970 auto CIAB 8: 38239 amiga serial TX 9: 0 amiga floppy_dma 12: 315934 amiga fb vertb handler 13: 315741 amiga serial status 15: 0 amiga DMA sound 19: 401 amiga serial RX 23: 1 cia floppy_timer 25: 0 cia amikbd 27: 456971 cia timer ERR: 0Quoted 2 lines
Seems like IRQ2 is very popular, so it's hard to say which device has generated the interrupts...
Yep - you'll be guaranteed to get a few IDE interrupts just by calling up cat - might be possible to get away without too much interrupts generated if it's all in the buffer cache - try whether the interrupt count changes after a few repetitions of that command.
Might require more elaborate IRQ bookkeeping though.
Quoted 8 lines
Quoted 1 line
I guess
scsi_esp_intr()is called a lot, as it's a shared interrupt?That's right - it will indeed be called a lot.
Quoted 2 lines
Can you add some debug prints there, to see if any of the conditions the esp core checks are met?
The code in question polls for completion in the ESP chip interrupt register, so checking in
scsi_esp_intrwon't help there. I suspect the ESP gets stuck because the DMA operation never completes. Wonder whether we can just do PIO insend_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
Quoted 4 lines · Tuomas Vainikka
The original blz1230 / blz2060 drivers did PIO commands. I attached a log of modprobing first without interrupt messages and then with the interrupt messages, because, indeed, the
zorro_esp_irq_pendingfunction gets called a lot, and it takes forever to printk those messages. I have no idea about the
You can use WARN_RATELIMIT() instead to avoid flooding the screen with the same values.printk_ratelimit() is similar, but it uses a single instance of the ratelimit state,
i.e. you cannot use it to limit two different value sets.
Quoted 3 lines
correct iomappings for the registers, nor do I know about the correct sizes for them. I have no idea where to use physical addresses and where to use virtual addresses...
When the CPU accesses memory, you have to use virtual addresses. When the DMA engine accesses memory, it has to use physical addresses.
Typically the DMA API is used to do the conversion
Quoted 2 lines
What is the difference between
ioremap()andZTWO_VADDR()and which one should be used where?
ioremap() is the generic way to map hardware registers into the CPU's virtual address space.
As the 16 MiB Zorro II address space is always mapped, you can use ZTWO_VADDR() for Zorro II addresses instead. This macro converts from physical Zorro II addresses to virtual kernel addresses.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 6 lines · Geert Uytterhoeven
Quoted 4 lines · Tuomas Vainikka
The original blz1230 / blz2060 drivers did PIO commands. I attached a log of modprobing first without interrupt messages and then with the interrupt messages, because, indeed, the
zorro_esp_irq_pendingfunction gets called a lot, and it takes forever to printk those messages. I have no idea about the
Quoted 7 lines
You can use
WARN_RATELIMIT()instead to avoid flooding the screen with the same values.printk_ratelimit()is similar, but it uses a single instance of the ratelimit state,
i.e. you cannot use it to limit two different value sets.
Ok, here's the suppressed output. Like Michael said, the short DMA command seems to be the problem, and should probably be sent using PIO.
-Tuomas