Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1272027 > unrolled thread

[PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

Started byFinn Thain <fthain@telegraphics.com.au>
First post2015-11-18 10:20 +0100
Last post2015-11-30 06:00 +0100
Articles 20 on this page of 44 — 5 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-18 10:20 +0100
    [PATCH 04/71] ncr5380: Remove more pointless macros Finn Thain <fthain@telegraphics.com.au> - 2015-11-18 10:30 +0100
    Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-18 12:40 +0100
      Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-19 03:30 +0100
        Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Michael Schmitz <schmitzmic@gmail.com> - 2015-11-19 04:00 +0100
        Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-19 08:50 +0100
        Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 00:00 +0100
          Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 02:50 +0100
            Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 08:30 +0100
              Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Christoph Hellwig <hch@infradead.org> - 2015-11-20 08:40 +0100
                Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 09:20 +0100
                  Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 10:20 +0100
                  Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Christoph Hellwig <hch@infradead.org> - 2015-11-20 11:10 +0100
                    Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-20 12:00 +0100
                      Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Christoph Hellwig <hch@infradead.org> - 2015-11-20 12:50 +0100
                      Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 12:50 +0100
                        Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-20 13:30 +0100
                          Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 13:50 +0100
            Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 08:40 +0100
            Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-20 19:30 +0100
              Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-21 03:10 +0100
                Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-21 14:10 +0100
                  Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-22 00:10 +0100
                  Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-22 00:40 +0100
                    Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 00:00 +0100
                      Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-24 02:30 +0100
                        Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 09:10 +0100
                          Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-24 10:20 +0100
                            Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 13:10 +0100
                              Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 19:10 +0100
                            Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-24 22:50 +0100
                              Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-25 03:20 +0100
                                Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-25 10:10 +0100
                                  Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380  drivers Finn Thain <fthain@telegraphics.com.au> - 2015-11-25 13:00 +0100
                                  Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers Ondrej Zary <linux@rainbow-software.org> - 2015-11-26 00:10 +0100
    [PATCH 72/71] ncr5380: Fix pseudo-DMA Ondrej Zary <linux@rainbow-software.org> - 2015-11-25 22:40 +0100
    [RFC PATCH 73/71] ncr5380: Use runtime register mapping Ondrej Zary <linux@rainbow-software.org> - 2015-11-29 10:50 +0100
      Re: [RFC PATCH 73/71] ncr5380: Use runtime register mapping Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 13:00 +0100
    [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Ondrej Zary <linux@rainbow-software.org> - 2015-11-29 10:50 +0100
      Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 13:00 +0100
      Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 13:10 +0100
        Re: [RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A Ondrej Zary <linux@rainbow-software.org> - 2015-11-30 14:50 +0100
    [RFC PATCH 75/71] ncr5380: Remove FLAG_DTC3181E Ondrej Zary <linux@rainbow-software.org> - 2015-11-29 11:10 +0100
      Re: [RFC PATCH 75/71] ncr5380: Remove FLAG_DTC3181E Finn Thain <fthain@telegraphics.com.au> - 2015-11-30 06:00 +0100

Page 1 of 3  [1] 2 3  Next page →


#1272027 — [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-18 10:20 +0100
Subject[PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qw6Bc-vx-5@gated-at.bofh.it>
Like my previous work on the NCR5380 drivers, this patch series has bug
fixes, code cleanup and modernization. These drivers suffer from mistakes,
poor style and neglect and this long series addresses the worst of it,
covering all ten wrapper drivers and both of the core driver forks. The
combined size of the drivers is reduced by about 750 LoC.

This series continues to reduce divergence between the two core driver
forks, often by copying a bug fix from one to the other. Most patches are
larger for having to keep the two forks in sync. Making the same change to
both is churn if one of them is to be removed but neither can be as yet.
By the end of this series the diff between the two forks is minimal, so it
becomes clear what caused the fork and what can be done about it.

This patch series did benefit from scripts/checkpatch.pl but not too much.
Decades ago, these drivers started out with 4-space tabs and if the 80
column limit were to be strictly enforced now, it would require adding new
functions and shortening identifiers. I would defer this sort of activity
until after the fork has been resolved.

I have compile-tested all patches to all NCR5380 drivers (x86, ARM, m68k)
and regression tested mac_scsi and dmx3191d modules on suitable hardware.
Testing the mac_scsi and dmx3191d modules provides only limited coverage.
It would be good to see some testing of ISA cards and Sun 3 and Atari
hardware too (I don't have any).

---
 drivers/scsi/Kconfig         |   17 
 drivers/scsi/NCR5380.c       | 2871 +++++++++++++++++++------------------------
 drivers/scsi/NCR5380.h       |   72 -
 drivers/scsi/arm/cumana_1.c  |   30 
 drivers/scsi/arm/oak.c       |   26 
 drivers/scsi/atari_NCR5380.c | 2295 +++++++++++++++-------------------
 drivers/scsi/atari_scsi.c    |  102 -
 drivers/scsi/dmx3191d.c      |   32 
 drivers/scsi/dtc.c           |  114 -
 drivers/scsi/dtc.h           |   45 
 drivers/scsi/g_NCR5380.c     |  178 +-
 drivers/scsi/g_NCR5380.h     |   56 
 drivers/scsi/mac_scsi.c      |  116 -
 drivers/scsi/pas16.c         |  115 -
 drivers/scsi/pas16.h         |   40 
 drivers/scsi/sun3_scsi.c     |  141 --
 drivers/scsi/t128.c          |  101 -
 drivers/scsi/t128.h          |   39 
 18 files changed, 2815 insertions(+), 3575 deletions(-)




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1272029 — [PATCH 04/71] ncr5380: Remove more pointless macros

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-18 10:30 +0100
Subject[PATCH 04/71] ncr5380: Remove more pointless macros
Message-ID<qw7dT-10j-3@gated-at.bofh.it>
In reply to#1272027
ASM macro is never defined. rtrc in pas16.c is not used.
NCR5380_map_config, do_NCR5380_intr, do_t128_intr and do_pas16_intr
are unused. NCR_NOT_SET harms readability. Remove them.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>

---
 drivers/scsi/NCR5380.h   |    3 ---
 drivers/scsi/g_NCR5380.c |   29 ++++++++++++++---------------
 drivers/scsi/g_NCR5380.h |    5 -----
 drivers/scsi/pas16.c     |   16 ----------------
 drivers/scsi/pas16.h     |    5 -----
 drivers/scsi/t128.h      |    4 ----
 6 files changed, 14 insertions(+), 48 deletions(-)

Index: linux/drivers/scsi/NCR5380.h
===================================================================
--- linux.orig/drivers/scsi/NCR5380.h	2015-11-18 19:25:56.000000000 +1100
+++ linux/drivers/scsi/NCR5380.h	2015-11-18 19:33:04.000000000 +1100
@@ -244,8 +244,6 @@
 #define FLAG_LATE_DMA_SETUP		32	/* Setup NCR before DMA H/W */
 #define FLAG_TAGGED_QUEUING		64	/* as X3T9.2 spelled it */
 
-#ifndef ASM
-
 #ifdef SUPPORT_TAGS
 struct tag_alloc {
 	DECLARE_BITMAP(allocated, MAX_TAGS);
@@ -443,5 +441,4 @@ static __inline__ int NCR5380_pc_dma_res
 #endif				/* defined(i386) || defined(__alpha__) */
 #endif				/* defined(REAL_DMA)  */
 #endif				/* __KERNEL__ */
-#endif				/* ndef ASM */
 #endif				/* NCR5380_H */
Index: linux/drivers/scsi/g_NCR5380.c
===================================================================
--- linux.orig/drivers/scsi/g_NCR5380.c	2015-11-18 19:32:59.000000000 +1100
+++ linux/drivers/scsi/g_NCR5380.c	2015-11-18 19:33:04.000000000 +1100
@@ -82,14 +82,13 @@
 #include <linux/delay.h>
 #include <linux/interrupt.h>
 
-#define NCR_NOT_SET 0
-static int ncr_irq = NCR_NOT_SET;
-static int ncr_dma = NCR_NOT_SET;
-static int ncr_addr = NCR_NOT_SET;
-static int ncr_5380 = NCR_NOT_SET;
-static int ncr_53c400 = NCR_NOT_SET;
-static int ncr_53c400a = NCR_NOT_SET;
-static int dtc_3181e = NCR_NOT_SET;
+static int ncr_irq;
+static int ncr_dma;
+static int ncr_addr;
+static int ncr_5380;
+static int ncr_53c400;
+static int ncr_53c400a;
+static int dtc_3181e;
 
 static struct override {
 	NCR5380_map_type NCR5380_map_name;
@@ -271,19 +270,19 @@ static int __init generic_NCR5380_detect
 	void __iomem *iomem;
 #endif
 
-	if (ncr_irq != NCR_NOT_SET)
+	if (ncr_irq)
 		overrides[0].irq = ncr_irq;
-	if (ncr_dma != NCR_NOT_SET)
+	if (ncr_dma)
 		overrides[0].dma = ncr_dma;
-	if (ncr_addr != NCR_NOT_SET)
+	if (ncr_addr)
 		overrides[0].NCR5380_map_name = (NCR5380_map_type) ncr_addr;
-	if (ncr_5380 != NCR_NOT_SET)
+	if (ncr_5380)
 		overrides[0].board = BOARD_NCR5380;
-	else if (ncr_53c400 != NCR_NOT_SET)
+	else if (ncr_53c400)
 		overrides[0].board = BOARD_NCR53C400;
-	else if (ncr_53c400a != NCR_NOT_SET)
+	else if (ncr_53c400a)
 		overrides[0].board = BOARD_NCR53C400A;
-	else if (dtc_3181e != NCR_NOT_SET)
+	else if (dtc_3181e)
 		overrides[0].board = BOARD_DTC3181E;
 #ifndef SCSI_G_NCR5380_MEM
 	if (!current_override && isapnp_present()) {
Index: linux/drivers/scsi/g_NCR5380.h
===================================================================
--- linux.orig/drivers/scsi/g_NCR5380.h	2015-11-18 19:25:56.000000000 +1100
+++ linux/drivers/scsi/g_NCR5380.h	2015-11-18 19:33:04.000000000 +1100
@@ -21,8 +21,6 @@
 #define NCR5380_BIOSPARAM NULL
 #endif
 
-#ifndef ASM
-
 #ifndef CMD_PER_LUN
 #define CMD_PER_LUN 2
 #endif
@@ -36,7 +34,6 @@
 
 #ifndef SCSI_G_NCR5380_MEM
 
-#define NCR5380_map_config port
 #define NCR5380_map_type int
 #define NCR5380_map_name port
 #define NCR5380_instance_name io_port
@@ -64,7 +61,6 @@
 #else 
 /* therefore SCSI_G_NCR5380_MEM */
 
-#define NCR5380_map_config memory
 #define NCR5380_map_type unsigned long
 #define NCR5380_map_name base
 #define NCR5380_instance_name base
@@ -103,6 +99,5 @@
 #define BOARD_NCR53C400A 2
 #define BOARD_DTC3181E	3
 
-#endif /* ndef ASM */
 #endif /* GENERIC_NCR5380_H */
 
Index: linux/drivers/scsi/pas16.c
===================================================================
--- linux.orig/drivers/scsi/pas16.c	2015-11-18 19:33:02.000000000 +1100
+++ linux/drivers/scsi/pas16.c	2015-11-18 19:33:04.000000000 +1100
@@ -145,22 +145,6 @@ static const unsigned short  pas16_offse
 		    * START_DMA_INITIATOR_RECEIVE_REG wo
 		    */
     };
-/*----------------------------------------------------------------*/
-/* the following will set the monitor border color (useful to find
- where something crashed or gets stuck at */
-/* 1 = blue
- 2 = green
- 3 = cyan
- 4 = red
- 5 = magenta
- 6 = yellow
- 7 = white
-*/
-#if 1
-#define rtrc(i) {inb(0x3da); outb(0x31, 0x3c0); outb((i), 0x3c0);}
-#else
-#define rtrc(i) {}
-#endif
 
 
 /*
Index: linux/drivers/scsi/pas16.h
===================================================================
--- linux.orig/drivers/scsi/pas16.h	2015-11-18 19:33:02.000000000 +1100
+++ linux/drivers/scsi/pas16.h	2015-11-18 19:33:04.000000000 +1100
@@ -95,9 +95,6 @@
 #define OPERATION_MODE_1 0xec03
 #define IO_CONFIG_3 0xf002
 
-
-#ifndef ASM
-
 #ifndef CMD_PER_LUN
 #define CMD_PER_LUN 2
 #endif
@@ -121,7 +118,6 @@
 #define NCR5380_write(reg, value) ( outb((value),PAS16_io_port(reg)) )
 
 #define NCR5380_intr pas16_intr
-#define do_NCR5380_intr do_pas16_intr
 #define NCR5380_queue_command pas16_queue_command
 #define NCR5380_abort pas16_abort
 #define NCR5380_bus_reset pas16_bus_reset
@@ -134,5 +130,4 @@
    
 #define PAS16_IRQS 0xd4a8 
 
-#endif /* ndef ASM */
 #endif /* PAS16_H */
Index: linux/drivers/scsi/t128.h
===================================================================
--- linux.orig/drivers/scsi/t128.h	2015-11-18 19:33:02.000000000 +1100
+++ linux/drivers/scsi/t128.h	2015-11-18 19:33:04.000000000 +1100
@@ -67,8 +67,6 @@
 
 #define T_DATA_REG_OFFSET	0x1e00	/* rw 512 bytes long */
 
-#ifndef ASM
-
 #ifndef CMD_PER_LUN
 #define CMD_PER_LUN 2
 #endif
@@ -92,7 +90,6 @@
 #define NCR5380_write(reg, value) writeb((value),(T128_address(reg)))
 
 #define NCR5380_intr t128_intr
-#define do_NCR5380_intr do_t128_intr
 #define NCR5380_queue_command t128_queue_command
 #define NCR5380_abort t128_abort
 #define NCR5380_bus_reset t128_bus_reset
@@ -105,5 +102,4 @@
 
 #define T128_IRQS 0xc4a8
 
-#endif /* ndef ASM */
 #endif /* T128_H */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1272106

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-18 12:40 +0100
Message-ID<qw9fH-2gd-17@gated-at.bofh.it>
In reply to#1272027
On Wednesday 18 November 2015, Finn Thain wrote:
> Like my previous work on the NCR5380 drivers, this patch series has bug
> fixes, code cleanup and modernization. These drivers suffer from mistakes,
> poor style and neglect and this long series addresses the worst of it,
> covering all ten wrapper drivers and both of the core driver forks. The
> combined size of the drivers is reduced by about 750 LoC.
>
> This series continues to reduce divergence between the two core driver
> forks, often by copying a bug fix from one to the other. Most patches are
> larger for having to keep the two forks in sync. Making the same change to
> both is churn if one of them is to be removed but neither can be as yet.
> By the end of this series the diff between the two forks is minimal, so it
> becomes clear what caused the fork and what can be done about it.
>
> This patch series did benefit from scripts/checkpatch.pl but not too much.
> Decades ago, these drivers started out with 4-space tabs and if the 80
> column limit were to be strictly enforced now, it would require adding new
> functions and shortening identifiers. I would defer this sort of activity
> until after the fork has been resolved.
>
> I have compile-tested all patches to all NCR5380 drivers (x86, ARM, m68k)
> and regression tested mac_scsi and dmx3191d modules on suitable hardware.
> Testing the mac_scsi and dmx3191d modules provides only limited coverage.
> It would be good to see some testing of ISA cards and Sun 3 and Atari
> hardware too (I don't have any).

I have some NCR5380 ISA cards and can test them.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1272749 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-19 03:30 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwn8Z-3aO-9@gated-at.bofh.it>
In reply to#1272106
On Wed, 18 Nov 2015, Ondrej Zary wrote:

> On Wednesday 18 November 2015, Finn Thain wrote:
> 
> > Like my previous work on the NCR5380 drivers, this patch series has 
> > bug fixes, code cleanup and modernization. These drivers suffer from 
> > mistakes, poor style and neglect and this long series addresses the 
> > worst of it, covering all ten wrapper drivers and both of the core 
> > driver forks. The combined size of the drivers is reduced by about 750 
> > LoC.
> >
> > This series continues to reduce divergence between the two core driver 
> > forks, often by copying a bug fix from one to the other. Most patches 
> > are larger for having to keep the two forks in sync. Making the same 
> > change to both is churn if one of them is to be removed but neither 
> > can be as yet. By the end of this series the diff between the two 
> > forks is minimal, so it becomes clear what caused the fork and what 
> > can be done about it.
> >
> > This patch series did benefit from scripts/checkpatch.pl but not too 
> > much. Decades ago, these drivers started out with 4-space tabs and if 
> > the 80 column limit were to be strictly enforced now, it would require 
> > adding new functions and shortening identifiers. I would defer this 
> > sort of activity until after the fork has been resolved.
> >
> > I have compile-tested all patches to all NCR5380 drivers (x86, ARM, 
> > m68k) and regression tested mac_scsi and dmx3191d modules on suitable 
> > hardware. Testing the mac_scsi and dmx3191d modules provides only 
> > limited coverage. It would be good to see some testing of ISA cards 
> > and Sun 3 and Atari hardware too (I don't have any).
> 
> I have some NCR5380 ISA cards and can test them.
> 

Thanks Ondrej. I've no idea which ISA drivers are presently working in 
mainline. Finding regressions may be more difficult than usual ;-)

Michael, Sam: only atari_scsi and sun3_scsi implement DMA support, so some
testing of either driver would be helpful.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1272771 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromMichael Schmitz <schmitzmic@gmail.com>
Date2015-11-19 04:00 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwnC2-3lg-13@gated-at.bofh.it>
In reply to#1272749
Hi Finn,

>>>
>>> I have compile-tested all patches to all NCR5380 drivers (x86, ARM, 
>>> m68k) and regression tested mac_scsi and dmx3191d modules on suitable 
>>> hardware. Testing the mac_scsi and dmx3191d modules provides only 
>>> limited coverage. It would be good to see some testing of ISA cards 
>>> and Sun 3 and Atari hardware too (I don't have any).
>>
>> I have some NCR5380 ISA cards and can test them.
>>
> 
> Thanks Ondrej. I've no idea which ISA drivers are presently working in 
> mainline. Finding regressions may be more difficult than usual ;-)
> 
> Michael, Sam: only atari_scsi and sun3_scsi implement DMA support, so some
> testing of either driver would be helpful.

One way or another, I'll test this series or get someone to test a
kernel I built.

Cheers,
	
	Michael



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1272900

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-19 08:50 +0100
Message-ID<qws8G-6mi-7@gated-at.bofh.it>
In reply to#1272749
On Thursday 19 November 2015, Finn Thain wrote:
> On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > On Wednesday 18 November 2015, Finn Thain wrote:
> > > Like my previous work on the NCR5380 drivers, this patch series has
> > > bug fixes, code cleanup and modernization. These drivers suffer from
> > > mistakes, poor style and neglect and this long series addresses the
> > > worst of it, covering all ten wrapper drivers and both of the core
> > > driver forks. The combined size of the drivers is reduced by about 750
> > > LoC.
> > >
> > > This series continues to reduce divergence between the two core driver
> > > forks, often by copying a bug fix from one to the other. Most patches
> > > are larger for having to keep the two forks in sync. Making the same
> > > change to both is churn if one of them is to be removed but neither
> > > can be as yet. By the end of this series the diff between the two
> > > forks is minimal, so it becomes clear what caused the fork and what
> > > can be done about it.
> > >
> > > This patch series did benefit from scripts/checkpatch.pl but not too
> > > much. Decades ago, these drivers started out with 4-space tabs and if
> > > the 80 column limit were to be strictly enforced now, it would require
> > > adding new functions and shortening identifiers. I would defer this
> > > sort of activity until after the fork has been resolved.
> > >
> > > I have compile-tested all patches to all NCR5380 drivers (x86, ARM,
> > > m68k) and regression tested mac_scsi and dmx3191d modules on suitable
> > > hardware. Testing the mac_scsi and dmx3191d modules provides only
> > > limited coverage. It would be good to see some testing of ISA cards
> > > and Sun 3 and Atari hardware too (I don't have any).
> >
> > I have some NCR5380 ISA cards and can test them.
>
> Thanks Ondrej. I've no idea which ISA drivers are presently working in
> mainline. Finding regressions may be more difficult than usual ;-)

I remember that at least one of them never worked in Linux - HP C2502 card 
with 53C400A chip with no jumpers (magic-numbers-based configuration).

The memory-mapped Canon FG2-5202 (53C400) did not work properly either.

At least DTCT-436P used to work.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273563

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-20 00:00 +0100
Message-ID<qwGlj-7bk-5@gated-at.bofh.it>
In reply to#1272749

On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > On Wednesday 18 November 2015, Finn Thain wrote:
> > > Like my previous work on the NCR5380 drivers, this patch series has
> > > bug fixes, code cleanup and modernization. These drivers suffer from
> > > mistakes, poor style and neglect and this long series addresses the
> > > worst of it, covering all ten wrapper drivers and both of the core
> > > driver forks. The combined size of the drivers is reduced by about 750
> > > LoC.
> > >
> > > This series continues to reduce divergence between the two core driver
> > > forks, often by copying a bug fix from one to the other. Most patches
> > > are larger for having to keep the two forks in sync. Making the same
> > > change to both is churn if one of them is to be removed but neither
> > > can be as yet. By the end of this series the diff between the two
> > > forks is minimal, so it becomes clear what caused the fork and what
> > > can be done about it.
> > >
> > > This patch series did benefit from scripts/checkpatch.pl but not too
> > > much. Decades ago, these drivers started out with 4-space tabs and if
> > > the 80 column limit were to be strictly enforced now, it would require
> > > adding new functions and shortening identifiers. I would defer this
> > > sort of activity until after the fork has been resolved.
> > >
> > > I have compile-tested all patches to all NCR5380 drivers (x86, ARM,
> > > m68k) and regression tested mac_scsi and dmx3191d modules on suitable
> > > hardware. Testing the mac_scsi and dmx3191d modules provides only
> > > limited coverage. It would be good to see some testing of ISA cards
> > > and Sun 3 and Atari hardware too (I don't have any).
> >
> > I have some NCR5380 ISA cards and can test them.
>
> Thanks Ondrej. I've no idea which ISA drivers are presently working in
> mainline. Finding regressions may be more difficult than usual ;-)

You're right... looks very broken:

[   62.577194] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA 
NCR53C400 }
[   62.796635] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
[   63.878494] sd 2:0:0:0: Attached scsi generic sg1 type 0
[   95.848260] sd 2:0:0:0: aborting command

And the system hangs completely.

It's much better with your patches, but still not great :)

[   93.963264] pnp 01:01.00: [io  0x0240-0x025f]
[   93.963493] pnp 01:01.00: [irq 5]
[   93.965768] pnp 01:01.00: activated
[   93.977147] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[   93.987527] scsi host2: rejecting message
[   93.987647] Synchronous Data Transfer Request period = 100 ns offset = 12
[   94.001219] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
[  113.000794] sd 2:0:0:0: Attached scsi generic sg1 type 0
[  144.852432] sd 2:0:0:0: [sdb] Unit Not Ready
[  144.852574] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
[  144.852713] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
[  240.108292] INFO: task modprobe:1957 blocked for more than 120 seconds.
[  240.108418]       Not tainted 4.3.0-rc1+ #74
[  240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.108597] modprobe        D 0000001a     0  1957   1950 0x00000000
[  240.108790]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
[  240.109246]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
[  240.109699]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
[  240.110156] Call Trace:
[  240.110295]  [<c139c504>] ? schedule+0x5b/0x67
[  240.110430]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  240.110569]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  240.110699]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  240.110824]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  240.110948]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  240.111068]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  240.852458] sd 2:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
[  240.852620] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
[  240.852760] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
[  272.852471] sd 2:0:0:0: [sdb] Write Protect is off
[  272.852614] sd 2:0:0:0: [sdb] Mode Sense: 00 00 00 00
[  304.084452] sd 2:0:0:0: [sdb] Asking for cache data failed
[  304.084592] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[  360.108284] INFO: task modprobe:1957 blocked for more than 120 seconds.
[  360.108409]       Not tainted 4.3.0-rc1+ #74
[  360.108492] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  360.108591] modprobe        D 0000001a     0  1957   1950 0x00000000
[  360.108787]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
[  360.109248]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
[  360.109703]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
[  360.110158] Call Trace:
[  360.110296]  [<c139c504>] ? schedule+0x5b/0x67
[  360.110430]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  360.110568]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  360.110699]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  360.110823]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  360.110945]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  360.111065]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  431.060488] sd 2:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
[  431.060650] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
[  431.060791] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
[  480.108282] INFO: task modprobe:1957 blocked for more than 120 seconds.
[  480.108405]       Not tainted 4.3.0-rc1+ #74
[  480.108488] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  480.108585] modprobe        D 0000001a     0  1957   1950 0x00000000
[  480.108779]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
[  480.109236]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
[  480.109689]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
[  480.110145] Call Trace:
[  480.110282]  [<c139c504>] ? schedule+0x5b/0x67
[  480.110417]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  480.110556]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  480.110685]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  480.110810]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  480.110932]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  480.111052]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  495.062082] sd 2:0:0:0: [sdb] Attached SCSI disk

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273668 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-20 02:50 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwIZQ-vP-11@gated-at.bofh.it>
In reply to#1273563
On Thu, 19 Nov 2015, Ondrej Zary wrote:

> On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
>
> > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> >
> > >
> > > I have some NCR5380 ISA cards and can test them.
> >
> > Thanks Ondrej. I've no idea which ISA drivers are presently working in 
> > mainline. Finding regressions may be more difficult than usual ;-)
> 
> You're right... looks very broken:
> 
> [   62.577194] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA 
> NCR53C400 }
> [   62.796635] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
> [   63.878494] sd 2:0:0:0: Attached scsi generic sg1 type 0
> [   95.848260] sd 2:0:0:0: aborting command
> 
> And the system hangs completely.
> 

Yes. That was the usual failure mode. The old EH abort routine is fatal. 
Up until I disabled PDMA by default for mac_scsi (in v3.19), that driver 
would do the same thing.

> It's much better with your patches, but still not great :)
> 

Pleased to hear it :)

> [   93.963264] pnp 01:01.00: [io  0x0240-0x025f]
> [   93.963493] pnp 01:01.00: [irq 5]
> [   93.965768] pnp 01:01.00: activated
> [   93.977147] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [   93.987527] scsi host2: rejecting message
> [   93.987647] Synchronous Data Transfer Request period = 100 ns offset = 12
> [   94.001219] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
> [  113.000794] sd 2:0:0:0: Attached scsi generic sg1 type 0

I'd be interested to know what commands were in play in that 19 second 
interval. Might need to use scsi_logging_level to figure that out.

My tests involved 3 different scsi targets (two disks and a CD-ROM) but 
none of these send a SDTR. Your log says the driver correctly rejected the 
SDTR message but that doesn't mean the target actually went to MSG IN 
phase and got the message. Do you have any older targets you can test?

> [  144.852432] sd 2:0:0:0: [sdb] Unit Not Ready
> [  144.852574] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> [  144.852713] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure

AFAIK, the target should not have to abort any commands. Moreover, the 
target should never experience a select/reselect failure, because you have 
irq == 0 (see above) and that implies that the target is never permitted 
the disconnect privilege.

> [  240.108292] INFO: task modprobe:1957 blocked for more than 120 seconds.
> [  240.108418]       Not tainted 4.3.0-rc1+ #74

Why not use v4.3?

> [  240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  240.108597] modprobe        D 0000001a     0  1957   1950 0x00000000
> [  240.108790]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
> [  240.109246]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
> [  240.109699]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
> [  240.110156] Call Trace:
> [  240.110295]  [<c139c504>] ? schedule+0x5b/0x67
> [  240.110430]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [  240.110569]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [  240.110699]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [  240.110824]  [<c107ddb5>] ? load_module+0x14de/0x18ca
> [  240.110948]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [  240.111068]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12

Not sure what module was being probed here. I presume it was g_NCR5380 or 
g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure what 
the implications are (?)

> [  240.852458] sd 2:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> [  240.852620] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> [  240.852760] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
> [  272.852471] sd 2:0:0:0: [sdb] Write Protect is off
> [  272.852614] sd 2:0:0:0: [sdb] Mode Sense: 00 00 00 00
> [  304.084452] sd 2:0:0:0: [sdb] Asking for cache data failed
> [  304.084592] sd 2:0:0:0: [sdb] Assuming drive cache: write through

This looks like nonsense to me ... I don't think the target actually 
aborted the reselection phase of a read capacity command. I'm out of ideas 
here. Can anyone else make sense of this?

> [  360.108284] INFO: task modprobe:1957 blocked for more than 120 seconds.
> [  360.108409]       Not tainted 4.3.0-rc1+ #74
> [  360.108492] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  360.108591] modprobe        D 0000001a     0  1957   1950 0x00000000
> [  360.108787]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
> [  360.109248]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
> [  360.109703]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
> [  360.110158] Call Trace:
> [  360.110296]  [<c139c504>] ? schedule+0x5b/0x67
> [  360.110430]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [  360.110568]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [  360.110699]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [  360.110823]  [<c107ddb5>] ? load_module+0x14de/0x18ca
> [  360.110945]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [  360.111065]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> [  431.060488] sd 2:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> [  431.060650] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> [  431.060791] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
> [  480.108282] INFO: task modprobe:1957 blocked for more than 120 seconds.
> [  480.108405]       Not tainted 4.3.0-rc1+ #74
> [  480.108488] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  480.108585] modprobe        D 0000001a     0  1957   1950 0x00000000
> [  480.108779]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
> [  480.109236]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
> [  480.109689]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
> [  480.110145] Call Trace:
> [  480.110282]  [<c139c504>] ? schedule+0x5b/0x67
> [  480.110417]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> [  480.110556]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> [  480.110685]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> [  480.110810]  [<c107ddb5>] ? load_module+0x14de/0x18ca
> [  480.110932]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> [  480.111052]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> [  495.062082] sd 2:0:0:0: [sdb] Attached SCSI disk
> 
> 

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273754 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-20 08:30 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwOiR-47v-1@gated-at.bofh.it>
In reply to#1273668
On Fri, 20 Nov 2015, I wrote:

> On Thu, 19 Nov 2015, Ondrej Zary wrote:
> 
> > [  240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [  240.108597] modprobe        D 0000001a     0  1957   1950 0x00000000
> > [  240.108790]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
> > [  240.109246]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
> > [  240.109699]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
> > [  240.110156] Call Trace:
> > [  240.110295]  [<c139c504>] ? schedule+0x5b/0x67
> > [  240.110430]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> > [  240.110569]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> > [  240.110699]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> > [  240.110824]  [<c107ddb5>] ? load_module+0x14de/0x18ca
> > [  240.110948]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> > [  240.111068]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> 
> Not sure what module was being probed here. I presume it was g_NCR5380 
> or g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure 
> what the implications are (?)

Nevermind. The call is in scsi_module.c.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273760 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-20 08:40 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwOsy-4aA-17@gated-at.bofh.it>
In reply to#1273754
On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
> > Not sure what module was being probed here. I presume it was g_NCR5380 
> > or g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure 
> > what the implications are (?)
> 
> Nevermind. The call is in scsi_module.c.

Which, btw really need to go away.  If you want to resurrect the
ISA drivers they need to be converted to proper probing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273813 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-20 09:20 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwP5g-4EO-33@gated-at.bofh.it>
In reply to#1273760
On Thu, 19 Nov 2015, Christoph Hellwig wrote:

> On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
>
> > > Not sure what module was being probed here. I presume it was 
> > > g_NCR5380 or g_NCR5380_mmio. Neither of these calls 
> > > 'scsi_scan_host'. I'm not sure what the implications are (?)
> > 
> > Nevermind. The call is in scsi_module.c.
> 
> Which, btw really need to go away.  If you want to resurrect the
> ISA drivers they need to be converted to proper probing.

Yes. I didn't do that conversion because I don't have ISA hardware and I 
don't understand ISA probing.

The present patch set doesn't seek to resurrect the ISA drivers. But I am 
trying to avoid regressions.

I have mixed feelings about the ISA drivers. ISA DMA support complicates 
things (it was never completed) and DMA seems to be the main obstacle to 
merging the two core driver forks.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273886

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-20 10:20 +0100
Message-ID<qwQ1k-5gs-3@gated-at.bofh.it>
In reply to#1273813
On Friday 20 November 2015, Finn Thain wrote:
> 
> On Thu, 19 Nov 2015, Christoph Hellwig wrote:
> 
> > On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
> >
> > > > Not sure what module was being probed here. I presume it was 
> > > > g_NCR5380 or g_NCR5380_mmio. Neither of these calls 
> > > > 'scsi_scan_host'. I'm not sure what the implications are (?)
> > > 
> > > Nevermind. The call is in scsi_module.c.
> > 
> > Which, btw really need to go away.  If you want to resurrect the
> > ISA drivers they need to be converted to proper probing.
> 
> Yes. I didn't do that conversion because I don't have ISA hardware and I 
> don't understand ISA probing.
> 
> The present patch set doesn't seek to resurrect the ISA drivers. But I am 
> trying to avoid regressions.
> 
> I have mixed feelings about the ISA drivers. ISA DMA support complicates 
> things (it was never completed) and DMA seems to be the main obstacle to 
> merging the two core driver forks.

IIRC, my ISA cards can't do DMA either.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273921 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-20 11:10 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwQNI-5O7-17@gated-at.bofh.it>
In reply to#1273813
On Fri, Nov 20, 2015 at 07:19:21PM +1100, Finn Thain wrote:
> Yes. I didn't do that conversion because I don't have ISA hardware and I 
> don't understand ISA probing.
> 
> The present patch set doesn't seek to resurrect the ISA drivers. But I am 
> trying to avoid regressions.
> 
> I have mixed feelings about the ISA drivers. ISA DMA support complicates 
> things (it was never completed) and DMA seems to be the main obstacle to 
> merging the two core driver forks.

I'd love to be able to get rid of the ISA drivers to be honest.  Given
that they appear to be gravely broken before your cleanups this might
be an opportunity to get rid of them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273977 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromFinn Thain <fthain@telegraphics.com.au>
Date2015-11-20 12:00 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwRA7-67v-35@gated-at.bofh.it>
In reply to#1273921
On Fri, 20 Nov 2015, Christoph Hellwig wrote:

> On Fri, Nov 20, 2015 at 07:19:21PM +1100, Finn Thain wrote:
>
> > Yes. I didn't do that conversion because I don't have ISA hardware and 
> > I don't understand ISA probing.
> > 
> > The present patch set doesn't seek to resurrect the ISA drivers. But I 
> > am trying to avoid regressions.
> > 
> > I have mixed feelings about the ISA drivers. ISA DMA support 
> > complicates things (it was never completed) and DMA seems to be the 
> > main obstacle to merging the two core driver forks.
> 
> I'd love to be able to get rid of the ISA drivers to be honest.

Is that because of their use of scsi_module.c or their general decrepitude 
or something else?

> Given that they appear to be gravely broken before your cleanups this 
> might be an opportunity to get rid of them.

At this stage, that's unclear (to me). It could be that g_NCR5380.c is not 
broken. It could be that the core driver can't handle certain targets. I 
think we need to do more testing.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273999 — Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-20 12:50 +0100
SubjectRe: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Message-ID<qwSmu-6EE-19@gated-at.bofh.it>
In reply to#1273977
On Fri, Nov 20, 2015 at 12:40:03PM +0100, Ondrej Zary wrote:
> > > I'd love to be able to get rid of the ISA drivers to be honest.
> > 
> > Is that because of their use of scsi_module.c or their general decrepitude 
> > or something else?
> 
> scsi_module.c usage shouldn't be hard to fix. I can do that after finding a working setup.

It's the general state of them.

> 
> > > Given that they appear to be gravely broken before your cleanups this 
> > > might be an opportunity to get rid of them.
> > 
> > At this stage, that's unclear (to me). It could be that g_NCR5380.c is not 
> > broken. It could be that the core driver can't handle certain targets. I 
> > think we need to do more testing.
> 
> Maybe I was just unlucky and tested a drive that never worked with this driver.
> 
> Working ISA means more testing possibilities. It's much easier to get an ISA card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means quicker testing.


Well, if you volunteer to bring the NCR5380 ISA drivers up to date and
maintain them it's obvuously fine to keep them around.

I'm more worried about all the unmaintained ISA drivers in horrible
shape.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1274003

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-20 12:50 +0100
Message-ID<qwSmu-6EE-21@gated-at.bofh.it>
In reply to#1273977
On Friday 20 November 2015, Finn Thain wrote:
> 
> On Fri, 20 Nov 2015, Christoph Hellwig wrote:
> 
> > On Fri, Nov 20, 2015 at 07:19:21PM +1100, Finn Thain wrote:
> >
> > > Yes. I didn't do that conversion because I don't have ISA hardware and 
> > > I don't understand ISA probing.
> > > 
> > > The present patch set doesn't seek to resurrect the ISA drivers. But I 
> > > am trying to avoid regressions.
> > > 
> > > I have mixed feelings about the ISA drivers. ISA DMA support 
> > > complicates things (it was never completed) and DMA seems to be the 
> > > main obstacle to merging the two core driver forks.
> > 
> > I'd love to be able to get rid of the ISA drivers to be honest.
> 
> Is that because of their use of scsi_module.c or their general decrepitude 
> or something else?

scsi_module.c usage shouldn't be hard to fix. I can do that after finding a working setup.

> > Given that they appear to be gravely broken before your cleanups this 
> > might be an opportunity to get rid of them.
> 
> At this stage, that's unclear (to me). It could be that g_NCR5380.c is not 
> broken. It could be that the core driver can't handle certain targets. I 
> think we need to do more testing.

Maybe I was just unlucky and tested a drive that never worked with this driver.

Working ISA means more testing possibilities. It's much easier to get an ISA card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means quicker testing.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1274033

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2015-11-20 13:30 +0100
Message-ID<qwSZd-79N-37@gated-at.bofh.it>
In reply to#1274003
On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary
<linux@rainbow-software.org> wrote:
> Working ISA means more testing possibilities. It's much easier to get an ISA card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means quicker testing.

Faster PCs without ISA slots? ;-)

Gr{oetje,eeting}s,

                        Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1274048

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-20 13:50 +0100
Message-ID<qwTiy-7gN-27@gated-at.bofh.it>
In reply to#1274033
On Friday 20 November 2015, Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary
> <linux@rainbow-software.org> wrote:
> > Working ISA means more testing possibilities. It's much easier to get an ISA card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means quicker testing.
> 
> Faster PCs without ISA slots? ;-)

Faster but not too fast, you have to be careful :)
There are many boards for Pentium 3 or Ahlon XP CPUs with ISA slots.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1273758

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-20 08:40 +0100
Message-ID<qwOsx-4aA-5@gated-at.bofh.it>
In reply to#1273668
On Friday 20 November 2015, Finn Thain wrote:
> 
> On Thu, 19 Nov 2015, Ondrej Zary wrote:
> 
> > On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> >
> > > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > I have some NCR5380 ISA cards and can test them.
> > >
> > > Thanks Ondrej. I've no idea which ISA drivers are presently working in 
> > > mainline. Finding regressions may be more difficult than usual ;-)
> > 
> > You're right... looks very broken:
> > 
> > [   62.577194] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> > sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA 
> > NCR53C400 }
> > [   62.796635] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
> > [   63.878494] sd 2:0:0:0: Attached scsi generic sg1 type 0
> > [   95.848260] sd 2:0:0:0: aborting command
> > 
> > And the system hangs completely.
> > 
> 
> Yes. That was the usual failure mode. The old EH abort routine is fatal. 
> Up until I disabled PDMA by default for mac_scsi (in v3.19), that driver 
> would do the same thing.
> 
> > It's much better with your patches, but still not great :)
> > 
> 
> Pleased to hear it :)
> 
> > [   93.963264] pnp 01:01.00: [io  0x0240-0x025f]
> > [   93.963493] pnp 01:01.00: [irq 5]
> > [   93.965768] pnp 01:01.00: activated
> > [   93.977147] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> > sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > [   93.987527] scsi host2: rejecting message
> > [   93.987647] Synchronous Data Transfer Request period = 100 ns offset = 12
> > [   94.001219] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
> > [  113.000794] sd 2:0:0:0: Attached scsi generic sg1 type 0
> 
> I'd be interested to know what commands were in play in that 19 second 
> interval. Might need to use scsi_logging_level to figure that out.
> 
> My tests involved 3 different scsi targets (two disks and a CD-ROM) but 
> none of these send a SDTR. Your log says the driver correctly rejected the 
> SDTR message but that doesn't mean the target actually went to MSG IN 
> phase and got the message. Do you have any older targets you can test?

Yes, I have some older disks too and also CD-ROMs. This one was just handy in
an external enclosure (the card has only an external DB25 connector). It can
be opened easily so I'll test the other devices too.

> > [  144.852432] sd 2:0:0:0: [sdb] Unit Not Ready
> > [  144.852574] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> > [  144.852713] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
> 
> AFAIK, the target should not have to abort any commands. Moreover, the 
> target should never experience a select/reselect failure, because you have 
> irq == 0 (see above) and that implies that the target is never permitted 
> the disconnect privilege.
> 
> > [  240.108292] INFO: task modprobe:1957 blocked for more than 120 seconds.
> > [  240.108418]       Not tainted 4.3.0-rc1+ #74
> 
> Why not use v4.3?

I had that already built so just quickly applied the patches and tested. I have
to update the git tree anyway as ACPI is broken.

> > [  240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [  240.108597] modprobe        D 0000001a     0  1957   1950 0x00000000
> > [  240.108790]  ce0fad00 00000086 53881781 0000001a c1525f88 4edbe39c 0000001a 04ac33e5
> > [  240.109246]  00000000 ccd54000 ffffffff ffffffff d204b280 c139c504 00000000 c104416d
> > [  240.109699]  00000000 ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 00000000 ccd6d100
> > [  240.110156] Call Trace:
> > [  240.110295]  [<c139c504>] ? schedule+0x5b/0x67
> > [  240.110430]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
> > [  240.110569]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
> > [  240.110699]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
> > [  240.110824]  [<c107ddb5>] ? load_module+0x14de/0x18ca
> > [  240.110948]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
> > [  240.111068]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
> 
> Not sure what module was being probed here. I presume it was g_NCR5380 or 
> g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure what 
> the implications are (?)

It was g_NCR5380 (DTCT-436P card).

> > [  240.852458] sd 2:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> > [  240.852620] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> > [  240.852760] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
> > [  272.852471] sd 2:0:0:0: [sdb] Write Protect is off
> > [  272.852614] sd 2:0:0:0: [sdb] Mode Sense: 00 00 00 00
> > [  304.084452] sd 2:0:0:0: [sdb] Asking for cache data failed
> > [  304.084592] sd 2:0:0:0: [sdb] Assuming drive cache: write through
> 
> This looks like nonsense to me ... I don't think the target actually 
> aborted the reselection phase of a read capacity command. I'm out of ideas 
> here. Can anyone else make sense of this?


-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1274332

FromOndrej Zary <linux@rainbow-software.org>
Date2015-11-20 19:30 +0100
Message-ID<qwYBz-2q0-5@gated-at.bofh.it>
In reply to#1273668
On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> 
> On Thu, 19 Nov 2015, Ondrej Zary wrote:
> 
> > On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> >
> > > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > I have some NCR5380 ISA cards and can test them.
> > >
> > > Thanks Ondrej. I've no idea which ISA drivers are presently working in 
> > > mainline. Finding regressions may be more difficult than usual ;-)
> > 
> > You're right... looks very broken:
> > 
> > [   62.577194] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> > sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA 
> > NCR53C400 }
> > [   62.796635] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
> > [   63.878494] sd 2:0:0:0: Attached scsi generic sg1 type 0
> > [   95.848260] sd 2:0:0:0: aborting command
> > 
> > And the system hangs completely.
> > 
> 
> Yes. That was the usual failure mode. The old EH abort routine is fatal. 
> Up until I disabled PDMA by default for mac_scsi (in v3.19), that driver 
> would do the same thing.
> 
> > It's much better with your patches, but still not great :)
> > 
> 
> Pleased to hear it :)
> 
> > [   93.963264] pnp 01:01.00: [io  0x0240-0x025f]
> > [   93.963493] pnp 01:01.00: [irq 5]
> > [   93.965768] pnp 01:01.00: activated
> > [   93.977147] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> > sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > [   93.987527] scsi host2: rejecting message
> > [   93.987647] Synchronous Data Transfer Request period = 100 ns offset = 12
> > [   94.001219] scsi 2:0:0:0: Direct-Access     IBM      0663             e    PQ: 0 ANSI: 2
> > [  113.000794] sd 2:0:0:0: Attached scsi generic sg1 type 0
> 
> I'd be interested to know what commands were in play in that 19 second 
> interval. Might need to use scsi_logging_level to figure that out.
> 
> My tests involved 3 different scsi targets (two disks and a CD-ROM) but 
> none of these send a SDTR. Your log says the driver correctly rejected the 
> SDTR message but that doesn't mean the target actually went to MSG IN 
> phase and got the message. Do you have any older targets you can test?

Another disk, without patches:

[   84.481582] pnp 01:01.00: activated
[   84.489650] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
[   84.953332] scsi 2:0:1:0: Direct-Access     QUANTUM  LP240S GM240S01X 4.6  PQ: 0 ANSI: 2 CCS
[   86.786475] sd 2:0:1:0: Attached scsi generic sg1 type 0
[   86.793753] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[   86.998555] sd 2:0:1:0: [sdb] Write Protect is off
[   87.406068] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  118.888271] sd 2:0:1:0: [sdb] aborting command
[  118.888738] sd 2:0:1:0: [sdb] aborting command

With patches:

[  258.473748] pnp 01:01.00: activated
[  258.483592] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[  261.347632] scsi 2:0:1:0: Direct-Access     QUANTUM  LP240S GM240S01X 4.6  PQ: 0 ANSI: 2 CCS
[  275.560451] sd 2:0:1:0: Attached scsi generic sg1 type 0
[  275.632519] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234 MiB)
[  275.635533] sd 2:0:1:0: [sdb] Write Protect is off
[  275.642315] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  469.076347] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
[  469.076613] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
[  469.076851] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
[  469.077086] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
[  469.077306] blk_update_request: I/O error, dev sdb, sector 2
[  469.077522] Buffer I/O error on dev sdb, logical block 1, async page read
[  480.108255] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
[  480.109773]       Not tainted 4.3.0-rc1+ #74
[  480.109973] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  480.110179] kworker/u2:2    D 00000040     0    60      2 0x00000000
[  480.110671] Workqueue: events_unbound async_run_entry_fn
[  480.110999]  cf9e8780 00000046 2eff25f7 00000040 c117f111 2ee82733 00000040 0016fec4
[  480.112390]  00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
[  480.113661]  00000040 cfaa5cfc c106f460 00161108 00000000 0000c648 2106dcce 00000040
[  480.114893] Call Trace:
[  480.115124]  [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
[  480.115344]  [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
[  480.115564]  [<c139c504>] ? schedule+0x5b/0x67
[  480.115794]  [<c139d9d3>] ? schedule_timeout+0x13/0xc5
[  480.116007]  [<c106f460>] ? timekeeping_get_ns+0x10/0x69
[  480.116406]  [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
[  480.116636]  [<c106fae7>] ? ktime_get+0x38/0x48
[  480.116843]  [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
[  480.117062]  [<c139c7f3>] ? bit_wait_io+0x21/0x26
[  480.117256]  [<c139c697>] ? __wait_on_bit+0x2f/0x5a
[  480.117486]  [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
[  480.117704]  [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
[  480.117942]  [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
[  480.118151]  [<c10ad386>] ? wait_on_page_read+0xf/0x2a
[  480.118373]  [<c10ae0e1>] ? do_read_cache_page+0x8e/0x116
[  480.118587]  [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
[  480.118809]  [<c10ae192>] ? read_cache_page+0x14/0x18
[  480.119008]  [<c1189b0e>] ? read_dev_sector+0x25/0x57
[  480.119222]  [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
[  480.119438]  [<c119a3f1>] ? vsnprintf+0x78/0x25d
[  480.119671]  [<c119a614>] ? snprintf+0x16/0x18
[  480.119874]  [<c118a7ea>] ? check_partition+0xd7/0x165
[  480.120253]  [<c118a067>] ? rescan_partitions+0x95/0x283
[  480.120443]  [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
[  480.120693]  [<c139cbc6>] ? mutex_lock+0x9/0x21
[  480.120915]  [<c1100046>] ? __blkdev_get+0x155/0x2f6
[  480.121133]  [<c110032f>] ? blkdev_get+0x148/0x258
[  480.121350]  [<c10ec747>] ? unlock_new_inode+0x36/0x3c
[  480.121570]  [<c10ff106>] ? bdget+0xdc/0xe6
[  480.121761]  [<c118854f>] ? add_disk+0x221/0x368
[  480.121996]  [<c126321a>] ? sd_probe_async+0xed/0x157
[  480.122214]  [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
[  480.122437]  [<c103f060>] ? process_one_work+0x130/0x21f
[  480.122639]  [<c103f2f6>] ? worker_thread+0x18a/0x247
[  480.122854]  [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
[  480.123069]  [<c1042c46>] ? kthread+0x7c/0x81
[  480.123288]  [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
[  480.123493]  [<c1042bca>] ? kthread_parkme+0x11/0x11
[  480.123733] INFO: task modprobe:1977 blocked for more than 120 seconds.
[  480.123919]       Not tainted 4.3.0-rc1+ #74
[  480.124239] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  480.124410] modprobe        D 00000040     0  1977   1969 0x00000000
[  480.124864]  cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
[  480.126123]  00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
[  480.127354]  00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
[  480.128746] Call Trace:
[  480.128961]  [<c139c504>] ? schedule+0x5b/0x67
[  480.129202]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  480.129449]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  480.129667]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  480.129899]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  480.130119]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  480.130346]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  502.100317] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
[  502.100578] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
[  502.100818] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
[  502.101057] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 02 00
[  502.101279] blk_update_request: I/O error, dev sdb, sector 4
[  502.101495] Buffer I/O error on dev sdb, logical block 2, async page read
[  600.128255] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
[  600.128486]       Not tainted 4.3.0-rc1+ #74
[  600.128687] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  600.128891] kworker/u2:2    D 00000040     0    60      2 0x00000000
[  600.129381] Workqueue: events_unbound async_run_entry_fn
[  600.129709]  cf9e8780 00000046 2eff25f7 00000040 c117f111 2ee82733 00000040 0016fec4
[  600.130941]  00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
[  600.132342]  00000040 cfaa5cfc c106f460 00161108 00000000 0000c648 2106dcce 00000040
[  600.133613] Call Trace:
[  600.133821]  [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
[  600.134065]  [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
[  600.134283]  [<c139c504>] ? schedule+0x5b/0x67
[  600.134509]  [<c139d9d3>] ? schedule_timeout+0x13/0xc5
[  600.134723]  [<c106f460>] ? timekeeping_get_ns+0x10/0x69
[  600.134948]  [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
[  600.135154]  [<c106fae7>] ? ktime_get+0x38/0x48
[  600.135377]  [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
[  600.135576]  [<c139c7f3>] ? bit_wait_io+0x21/0x26
[  600.135788]  [<c139c697>] ? __wait_on_bit+0x2f/0x5a
[  600.136000]  [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
[  600.136399]  [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
[  600.136607]  [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
[  600.136838]  [<c10ad386>] ? wait_on_page_read+0xf/0x2a
[  600.137044]  [<c10ae0e1>] ? do_read_cache_page+0x8e/0x116
[  600.137276]  [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
[  600.137481]  [<c10ae192>] ? read_cache_page+0x14/0x18
[  600.137699]  [<c1189b0e>] ? read_dev_sector+0x25/0x57
[  600.137901]  [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
[  600.138131]  [<c119a3f1>] ? vsnprintf+0x78/0x25d
[  600.138329]  [<c119a614>] ? snprintf+0x16/0x18
[  600.138544]  [<c118a7ea>] ? check_partition+0xd7/0x165
[  600.138738]  [<c118a067>] ? rescan_partitions+0x95/0x283
[  600.138962]  [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
[  600.139189]  [<c139cbc6>] ? mutex_lock+0x9/0x21
[  600.139427]  [<c1100046>] ? __blkdev_get+0x155/0x2f6
[  600.139632]  [<c110032f>] ? blkdev_get+0x148/0x258
[  600.139865]  [<c10ec747>] ? unlock_new_inode+0x36/0x3c
[  600.140263]  [<c10ff106>] ? bdget+0xdc/0xe6
[  600.140448]  [<c118854f>] ? add_disk+0x221/0x368
[  600.140689]  [<c126321a>] ? sd_probe_async+0xed/0x157
[  600.140908]  [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
[  600.141133]  [<c103f060>] ? process_one_work+0x130/0x21f
[  600.141336]  [<c103f2f6>] ? worker_thread+0x18a/0x247
[  600.141552]  [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
[  600.141764]  [<c1042c46>] ? kthread+0x7c/0x81
[  600.141982]  [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
[  600.142186]  [<c1042bca>] ? kthread_parkme+0x11/0x11
[  600.142426] INFO: task modprobe:1977 blocked for more than 120 seconds.
[  600.142612]       Not tainted 4.3.0-rc1+ #74
[  600.142787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  600.142991] modprobe        D 00000040     0  1977   1969 0x00000000
[  600.143444]  cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
[  600.144819]  00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
[  600.146052]  00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
[  600.147279] Call Trace:
[  600.147489]  [<c139c504>] ? schedule+0x5b/0x67
[  600.147729]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  600.147992]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  600.148390]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  600.148627]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  600.148846]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  600.149073]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  662.100333] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
[  662.100598] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
[  662.100838] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
[  662.101076] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 06 00 00 02 00
[  662.101297] blk_update_request: I/O error, dev sdb, sector 6
[  662.101512] Buffer I/O error on dev sdb, logical block 3, async page read
[  720.148270] INFO: task modprobe:1977 blocked for more than 120 seconds.
[  720.148499]       Not tainted 4.3.0-rc1+ #74
[  720.148699] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  720.148903] modprobe        D 00000040     0  1977   1969 0x00000000
[  720.149360]  cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
[  720.150615]  00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
[  720.151836]  00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
[  720.153221] Call Trace:
[  720.153465]  [<c139c504>] ? schedule+0x5b/0x67
[  720.153689]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  720.153931]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  720.154149]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  720.154379]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  720.154593]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  720.154820]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  781.025039] systemd-logind[1942]: New session c2 of user rainbow.
[  840.152254] INFO: task kworker/u2:2:60 blocked for more than 120 seconds.
[  840.152486]       Not tainted 4.3.0-rc1+ #74
[  840.152693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.152903] kworker/u2:2    D 0000009a     0    60      2 0x00000000
[  840.153399] Workqueue: events_unbound async_run_entry_fn
[  840.153730]  cf9e8780 00000046 2860b1ff 0000009a c117f111 284404dd 0000009a 001cad22
[  840.156408]  00000000 cfaa6000 00000000 7fffffff c139c7d2 c139c504 7fffffff c139d9d3
[  840.157689]  0000009a cfaa5c64 c106f460 00161e18 00000000 00013d94 006b70ce 0000009a
[  840.158925] Call Trace:
[  840.159158]  [<c117f111>] ? blk_queue_bio+0x1e8/0x1fb
[  840.159379]  [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
[  840.159600]  [<c139c504>] ? schedule+0x5b/0x67
[  840.159834]  [<c139d9d3>] ? schedule_timeout+0x13/0xc5
[  840.160052]  [<c106f460>] ? timekeeping_get_ns+0x10/0x69
[  840.160446]  [<c139c7d2>] ? bit_wait_io_timeout+0x3d/0x3d
[  840.160677]  [<c106fae7>] ? ktime_get+0x38/0x48
[  840.160884]  [<c139bf83>] ? io_schedule_timeout+0x83/0xd7
[  840.161105]  [<c139c7f3>] ? bit_wait_io+0x21/0x26
[  840.161306]  [<c139c697>] ? __wait_on_bit+0x2f/0x5a
[  840.161541]  [<c10ad361>] ? wait_on_page_bit+0x57/0x5e
[  840.161767]  [<c1054a98>] ? wake_atomic_t_function+0x2a/0x2a
[  840.161997]  [<c10ad386>] ? wait_on_page_read+0xf/0x2a
[  840.162206]  [<c10ae14f>] ? do_read_cache_page+0xfc/0x116
[  840.162445]  [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
[  840.162651]  [<c10ae192>] ? read_cache_page+0x14/0x18
[  840.162872]  [<c1189b0e>] ? read_dev_sector+0x25/0x57
[  840.163073]  [<c118e22f>] ? read_lba+0x94/0x10b
[  840.163289]  [<c118e7eb>] ? efi_partition+0xbc/0x451
[  840.163506]  [<c10b5c33>] ? put_page+0x16/0x24
[  840.163732]  [<c10ad39d>] ? wait_on_page_read+0x26/0x2a
[  840.163968]  [<c10ff1eb>] ? blkdev_readpages+0x15/0x15
[  840.164348]  [<c10ae192>] ? read_cache_page+0x14/0x18
[  840.164541]  [<c118a8a8>] ? adfspart_check_ICS+0x30/0x1ac
[  840.164777]  [<c119a3f1>] ? vsnprintf+0x78/0x25d
[  840.164977]  [<c119a614>] ? snprintf+0x16/0x18
[  840.165187]  [<c118a7ea>] ? check_partition+0xd7/0x165
[  840.165382]  [<c118a067>] ? rescan_partitions+0x95/0x283
[  840.165603]  [<c1254b50>] ? scsi_block_when_processing_errors+0x13/0xae
[  840.165829]  [<c139cbc6>] ? mutex_lock+0x9/0x21
[  840.166066]  [<c1100046>] ? __blkdev_get+0x155/0x2f6
[  840.166270]  [<c110032f>] ? blkdev_get+0x148/0x258
[  840.166501]  [<c10ec747>] ? unlock_new_inode+0x36/0x3c
[  840.166707]  [<c10ff106>] ? bdget+0xdc/0xe6
[  840.166914]  [<c118854f>] ? add_disk+0x221/0x368
[  840.167134]  [<c126321a>] ? sd_probe_async+0xed/0x157
[  840.167372]  [<c10443a0>] ? async_run_entry_fn+0x2c/0xad
[  840.167582]  [<c103f060>] ? process_one_work+0x130/0x21f
[  840.167802]  [<c103f2f6>] ? worker_thread+0x18a/0x247
[  840.168006]  [<c103f16c>] ? process_scheduled_works+0x1d/0x1d
[  840.168416]  [<c1042c46>] ? kthread+0x7c/0x81
[  840.168642]  [<c139e201>] ? ret_from_kernel_thread+0x21/0x30
[  840.168847]  [<c1042bca>] ? kthread_parkme+0x11/0x11
[  840.169094] INFO: task modprobe:1977 blocked for more than 120 seconds.
[  840.169281]       Not tainted 4.3.0-rc1+ #74
[  840.169454] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.169659] modprobe        D 00000040     0  1977   1969 0x00000000
[  840.170114]  cfb20000 00000086 29042653 00000040 c1525f88 28a83a17 00000040 005bec3c
[  840.171368]  00000000 ccdd0000 ffffffff ffffffff d2057280 c139c504 00000000 c104416d
[  840.172741]  00000000 cfb20000 c1054a45 c151fd8c c151fd8c d2057280 00000000 ccd621f0
[  840.173986] Call Trace:
[  840.174200]  [<c139c504>] ? schedule+0x5b/0x67
[  840.174443]  [<c104416d>] ? async_synchronize_cookie_domain+0x73/0x9f
[  840.174689]  [<c1054a45>] ? abort_exclusive_wait+0x6e/0x6e
[  840.174910]  [<c10ac9bc>] ? do_init_module+0xa4/0x1a3
[  840.175141]  [<c107ddb5>] ? load_module+0x14de/0x18ca
[  840.175359]  [<c107e2a0>] ? SyS_finit_module+0x47/0x56
[  840.175607]  [<c139e2c0>] ? sysenter_do_call+0x12/0x12
[  856.020359] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
[  856.020623] sd 2:0:1:0: [sdb] Sense Key : Aborted Command [current]
[  856.020862] sd 2:0:1:0: [sdb] Add. Sense: No additional sense information
[  856.021101] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
[  856.021324] blk_update_request: I/O error, dev sdb, sector 2
[  856.021539] Buffer I/O error on dev sdb, logical block 1, async page read
[  857.025325] sd 2:0:1:0: [sdb] FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  857.025596] sd 2:0:1:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 02 00
[  857.025830] blk_update_request: I/O error, dev sdb, sector 4
[  857.026043] Buffer I/O error on dev sdb, logical block 2, async page read
                             
                             
And a CD-ROM, first without patches:
[  655.929795] pnp 01:01.00: activated
[  655.939503] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
[  656.441943] scsi 2:0:2:0: CD-ROM            SONY     CD-ROM CDU-55S   1.0t PQ: 0 ANSI: 2
[  657.829087] scsi 2:0:2:0: Attached scsi generic sg1 type 5
[  658.325517] sr 2:0:2:0: [sr0] scsi-1 drive
[  658.325731] cdrom: Uniform CD-ROM driver Revision: 3.20

Modprobe succeeded but mount resulted in this & hang:
[  694.056266] sr 2:0:2:0: [sr0] aborting command

Then with patches:

[  109.753273] pnp 01:01.00: activated
[  109.763039] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[  115.456294] scsi 2:0:2:0: CD-ROM            SONY     CD-ROM CDU-55S   1.0t PQ: 0 ANSI: 2
[  126.823400] scsi 2:0:2:0: Attached scsi generic sg1 type 5
[  126.909680] sr 2:0:2:0: [sr0] scsi-1 drive
[  126.909888] cdrom: Uniform CD-ROM driver Revision: 3.20

Modprobe succeeded but mount failed after some time with this:
[ 1005.149546] sr 2:0:2:0: [sr0] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1005.149764] sr 2:0:2:0: [sr0] Sense Key : Illegal Request [current]
[ 1005.149992] sr 2:0:2:0: [sr0] Add. Sense: Logical block address out of range
[ 1005.150222] sr 2:0:2:0: [sr0] CDB: Read(10) 28 00 00 05 7a 94 00 00 02 00
[ 1005.150433] blk_update_request: critical target error, dev sr0, sector 1436240
[ 1005.154101] sr 2:0:2:0: [sr0] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1005.154309] sr 2:0:2:0: [sr0] Sense Key : Illegal Request [current]
[ 1005.154533] sr 2:0:2:0: [sr0] Add. Sense: Logical block address out of range
[ 1005.156209] sr 2:0:2:0: [sr0] CDB: Read(10) 28 00 00 05 7a 94 00 00 02 00
[ 1005.156404] blk_update_request: critical target error, dev sr0, sector 1436240
[ 1005.156607] Buffer I/O error on dev sr0, logical block 179530, async page read

mount: unknown filesystem type 'iso9660'

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel


csiph-web