ncr5380: Miscellaneous minor patches

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Finn" == Finn Thain <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Finn" == Finn Thain <[email protected]> writes:

Finn> Michael, Ondrej, can I get you to review/test please?

Pretty please!

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Michael" == Michael Schmitz <[email protected]> writes:

This series removes some unused code and related comments, addresses the warnings generated by 'make W=1' and 'make C=1' and fixes a theoretical bug in the bus reset method in atari_scsi.

There's also a patch to add a missing error check during target selection. The only target I tested was a QUANTUM DAYTONA514S disk as that's all I have access to right now. Some testing with other targets would be prudent.

Michael, Ondrej, can I get you to review/test please?

Quoted 10 lines · On Monday 16 January 2017 00:50:57 Finn Thain wrote:

This series removes some unused code and related comments, addresses the warnings generated by 'make W=1' and 'make C=1' and fixes a theoretical bug in the bus reset method in atari_scsi.

There's also a patch to add a missing error check during target selection. The only target I tested was a QUANTUM DAYTONA514S disk as that's all I have access to right now. Some testing with other targets would be prudent.

Michael, Ondrej, can I get you to review/test please?

Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip), DTC-3181L (DTCT-436P chip) and MS-PNR (53C400A chip) ISA cards - everything works fine!

Targets tested:

QUANTUM  LP240S GM240S01X
IBM      DORS-32160
IBM      0663L12

Thanks.

Tested-by Ondrej Zary <[email protected]>

Quoted 21 lines · Ondrej Zary

Quoted 10 lines · On Monday 16 January 2017 00:50:57 Finn Thain wrote:

This series removes some unused code and related comments, addresses the warnings generated by 'make W=1' and 'make C=1' and fixes a theoretical bug in the bus reset method in atari_scsi.

There's also a patch to add a missing error check during target selection. The only target I tested was a QUANTUM DAYTONA514S disk as that's all I have access to right now. Some testing with other targets would be prudent.

Michael, Ondrej, can I get you to review/test please?

Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip), DTC-3181L (DTCT-436P chip) and MS-PNR (53C400A chip) ISA cards - everything works fine!

Targets tested:

QUANTUM  LP240S GM240S01X
IBM      DORS-32160
IBM      0663L12

Quoted 3 lines

Thanks.

Tested-by Ondrej Zary <[email protected]>

Very helpful. Thank you, Ondrej.

Also tested two CD-ROM drives and they didn't work (machine hangs). They didn't work before and looks like they never worked with PDMA.

The fundamental problem of PDMA is that it either transfers all required data or it breaks horribly. Even when I added timeouts to the possibly infinite loops (to avoid hangs), the chip remained in some bad state. Sometimes the 53C80 gated IRQ check triggers. This can be hopefully fixed but there is a HW limitation: if less than 128 bytes were read from SCSI device, they get lost in chip buffer (the 128B buffers don't swap until full).

Fortunately, most of the requests for too much data are bogus. The problem is that generic_NCR5380_dma_xfer_len() uses cmd->transfersize which seems to be wrong. All other NCR5380 drivers use cmd->SCp.this_residual.

This is also why rescan-scsi-bus hangs (cmd->transfersize is 8192 but cmd->SCp.this_residual is only 96).

This quick fix allows CD-ROM and also rescan-scsi-bus to work. But it's not complete. Seems that we need:
- fix pread and pwrite to terminate gracefully

- something like atari_scsi_dma_xfer_len to allow DMA only for block commands

(quoted diff) +1 -7

@@ -588,22 +619,19 @@ static inline int generic_NCR5380_pwrite(struct NCR5380_hostdata *hostdata,
 static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
                                         struct scsi_cmnd *cmd)
 {
-       int transfersize = cmd->transfersize;
+       int transfersize = cmd->SCp.this_residual;
 
        if (hostdata->flags & FLAG_NO_PSEUDO_DMA)
                return 0;
 
-       /* Limit transfers to 32K, for xx400 & xx406
-        * pseudoDMA that transfers in 128 bytes blocks.
-        */
-       if (transfersize > 32 * 1024 && cmd->SCp.this_residual &&
-           !(cmd->SCp.this_residual % transfersize))
-               transfersize = 32 * 1024;

(quoted diff) +0 -0

 }
 

Are you trying to figure out which commands are going to disconnect during a transfer? This is really a function of the firmware in the target; there are no good heuristics AFAICT, so the PDMA algorithm has to be robust. mac_scsi has to cope with this too.

Does the problem go away when you assign no IRQ? When instance->irq == NO_IRQ, the core driver will inhibit disconnect privileges.

On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
[...]

Quoted 5 lines

Are you trying to figure out which commands are going to disconnect during a transfer? This is really a function of the firmware in the target; there are no good heuristics AFAICT, so the PDMA algorithm has to be robust. mac_scsi has to cope with this too.

Quoted 2 lines

Does the problem go away when you assign no IRQ? When instance->irq == NO_IRQ, the core driver will inhibit disconnect privileges.

Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ enabled, "dd if=/dev/sr0 of=anything" stops after a while.

I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.

When I enable interrupts during PDMA (like the removed UNSAFE macro did), the problems go away. I see an IRQ after each pread call.

(had to disable "no 53C80 gated irq after transfer" and "no end dma signal" messages to reduce log spam)

Quoted 11 lines · Ondrej Zary

On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
[...]

Quoted 7 lines

Are you trying to figure out which commands are going to disconnect during a transfer? This is really a function of the firmware in the target; there are no good heuristics AFAICT, so the PDMA algorithm has to be robust. mac_scsi has to cope with this too.

Does the problem go away when you assign no IRQ? When instance->irq == NO_IRQ, the core driver will inhibit disconnect privileges.

Quoted 2 lines

Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ enabled, "dd if=/dev/sr0 of=anything" stops after a while.

When you say "stops", do you mean an infinite loop in generic_NCR5380_pread or does the loop complete (which would presumably leave the target stuck in DATA IN phase, and a scsi command timeout would probably follow after 30 seconds...)

Quoted 1 line

I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.

You can use NCR5380_print() to get a decoded register dump.

When I decode the above values I get,

BASR = 0x10 = BASR_IRQ
MODE = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO

Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, which shows that the target has given up on the DATA IN phase and is presumably trying to send a DISCONNECT message.

Quoted 2 lines

When I enable interrupts during PDMA (like the removed UNSAFE macro did), the problems go away. I see an IRQ after each pread call.

You shouldn't need an interrupt, because NCR5380_dma_complete() gets called regardless. AFAICT, the only difference is the timing, which becomes less predictable. Calling spinlock_irq_restore() before the transfer seems to create a race condition between hostdata->dma_len store and load.

I think that the pread call has not yet returned when the interrupt fires and NCR5380_dma_complete() is called. Hence hostdata->dma_len has not yet been initialized. So when NCR5380_dma_complete() is called by the interrupt handler, SCp.this_residual will not change at all because hostdata->dma_len is still zero.

Quoted 2 lines

(had to disable "no 53C80 gated irq after transfer" and "no end dma signal" messages to reduce log spam)

That may provide a quick way to detect the failed PDMA transfer, at least for testing purposes. There may be a more conclusive test for a partial transfer.

We could to implement something like macscsi_dma_residual() to take care of a failed PDMA transfer. That way, the failure can be taken into account when NCR5380_dma_complete() is called at the end of the transfer.

See patch below for example. It should confirm the theory above though it really needs some timeouts added (NCR5380_poll_politely()). And perhaps we could do something more clever than retry indefinitely, though we can still rely on the command timeout.

drivers/scsi/g_NCR5380.c +4 -2

index 6f9665d..75cfaf3 100644
@@ -497,15 +497,17 @@ static inline int generic_NCR5380_pread(struct
 NCR5380_hostdata *hostdata, blocks--;
 	}
 
+	hostdata->pdma_residual = 0;
+
 	if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-		printk("53C400r: no 53C80 gated irq after transfer");
+		hostdata->pdma_residual = hostdata->dma_len;
 
 	/* wait for 53C80 registers to be available */
 	while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
 		;
 
 	if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
-		printk(KERN_ERR "53C400r: no end dma signal\n");
+		hostdata->pdma_residual = hostdata->dma_len;
 
 	return 0;
 }

@@ -576,12 +578,14 @@ static inline int generic_NCR5380_pwrite(struct

NCR5380_hostdata *hostdata, /* FIXME - no timeout */

drivers/scsi/g_NCR5380.c +10 -3

 	}
 
-	if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER)) {
-		printk(KERN_ERR "53C400w: no end dma signal\n");
-	}
+	hostdata->pdma_residual = 0;
+
+	if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
+		hostdata->pdma_residual = hostdata->dma_len;
 
 	while (!(NCR5380_read(TARGET_COMMAND_REG) & TCR_LAST_BYTE_SENT))
 		; 	// TIMEOUT
+
 	return 0;
 }

@@ -607,6 +611,11 @@ static int generic_NCR5380_dma_xfer_len(struct
 NCR5380_hostdata *hostdata, return transfersize;
 }
 
+static int generic_NCR5380_dma_residual(struct NCR5380_hostdata *hostdata)
+{
+	return hostdata->pdma_residual;
+}
+
 /*
  *	Include the NCR5380 core code that we build our driver around
  */

drivers/scsi/g_NCR5380.h +3 -2

index 81b22d9..08c91b7 100644
@@ -26,7 +26,8 @@
 	int c400_ctl_status; \
 	int c400_blk_cnt; \
 	int c400_host_buf; \
-	int io_width;
+	int io_width; \
+	int pdma_residual;
 
 #define NCR53C400_mem_base 0x3880
 #define NCR53C400_host_buffer 0x3900

@@ -35,7 +36,7 @@
 #define NCR5380_dma_xfer_len		generic_NCR5380_dma_xfer_len
 #define NCR5380_dma_recv_setup		generic_NCR5380_pread
 #define NCR5380_dma_send_setup		generic_NCR5380_pwrite
-#define NCR5380_dma_residual		NCR5380_dma_residual_none
+#define NCR5380_dma_residual		generic_NCR5380_dma_residual
 
 #define NCR5380_intr generic_NCR5380_intr
 #define NCR5380_queue_command generic_NCR5380_queue_command

Quoted 17 lines · On Friday 17 February 2017 23:38:12 Finn Thain wrote:

Quoted 15 lines · Ondrej Zary

On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
[...]

Quoted 9 lines

Are you trying to figure out which commands are going to disconnect during a transfer? This is really a function of the firmware in the target; there are no good heuristics AFAICT, so the PDMA algorithm has to be robust. mac_scsi has to cope with this too.

Does the problem go away when you assign no IRQ? When instance->irq == NO_IRQ, the core driver will inhibit disconnect privileges.

Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ enabled, "dd if=/dev/sr0 of=anything" stops after a while.

Quoted 4 lines

When you say "stops", do you mean an infinite loop in generic_NCR5380_pread or does the loop complete (which would presumably leave the target stuck in DATA IN phase, and a scsi command timeout would probably follow after 30 seconds...)

I've added timeouts to the possibly-infinite loops. It times out waiting for the host buffer to become ready.

Then everything breaks. Now I found why: pread() returns without waiting for the 53C80 registers to be ready.

Adding the wait allows to continue in PIO mode with "tag#0 switching to slow handshake".

Quoted 6 lines

Quoted 1 line

I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.

You can use NCR5380_print() to get a decoded register dump.

When I decode the above values I get,

Quoted 8 lines

BASR = 0x10 = BASR_IRQ
MODE = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO

Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, which shows that the target has given up on the DATA IN phase and is presumably trying to send a DISCONNECT message.

Looks you're right. The transfersize is 4096, i.e. 2 CD-ROM sectors. When the 2nd sector is not ready in the drive internal buffer, the drive probably disconnects which breaks the fragile pdma transfer. When the transfersize is limited to 2048 bytes, the problem goes away.

The problem also went away with enabled interrupts because I had some debug printks added which were slowing down the transfer enough for the drive (SONY CDU-55S) to keep up and not disconnect. Got the same result by inserting udelay(100) after each 128 byte block trasnferred in pread().

Quoted 3 lines

Quoted 2 lines

When I enable interrupts during PDMA (like the removed UNSAFE macro did), the problems go away. I see an IRQ after each pread call.

Quoted 18 lines · Ondrej Zary

Quoted 17 lines · On Friday 17 February 2017 23:38:12 Finn Thain wrote:

Quoted 15 lines · Ondrej Zary

On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
[...]

Quoted 9 lines

Are you trying to figure out which commands are going to disconnect during a transfer? This is really a function of the firmware in the target; there are no good heuristics AFAICT, so the PDMA algorithm has to be robust. mac_scsi has to cope with this too.

Does the problem go away when you assign no IRQ? When instance->irq == NO_IRQ, the core driver will inhibit disconnect privileges.

Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ enabled, "dd if=/dev/sr0 of=anything" stops after a while.

Quoted 7 lines

Quoted 4 lines

When you say "stops", do you mean an infinite loop in generic_NCR5380_pread or does the loop complete (which would presumably leave the target stuck in DATA IN phase, and a scsi command timeout would probably follow after 30 seconds...)

I've added timeouts to the possibly-infinite loops. It times out waiting for the host buffer to become ready.

In mac_scsi you'll find that the PDMA loop exploits the 15ms poll_politely time limit to give the target device time to catch up. You might want to do something similar.

Quoted 2 lines

Then everything breaks. Now I found why: pread() returns without waiting for the 53C80 registers to be ready.

Ouch! You can't return control to the core driver when the 53C80 core is unavailable. That would need special handling: the core driver would have to fail the scsi command and reset the device (and bus), based on the result you return from NCR5380_dma_recv_setup/NCR5380_dma_send_setup.

Quoted 2 lines

Adding the wait allows to continue in PIO mode with "tag#0 switching to slow handshake".

I don't think this is the code path you want. The target isn't really broken. But yes, we could use PIO as a slow workaround for fragile PDMA logic.

Quoted 15 lines

Quoted 6 lines

Quoted 1 line

I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.

You can use NCR5380_print() to get a decoded register dump.

When I decode the above values I get,

Quoted 8 lines

BASR = 0x10 = BASR_IRQ
MODE = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO

Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, which shows that the target has given up on the DATA IN phase and is presumably trying to send a DISCONNECT message.

Quoted 4 lines

Looks you're right. The transfersize is 4096, i.e. 2 CD-ROM sectors. When the 2nd sector is not ready in the drive internal buffer, the drive probably disconnects which breaks the fragile pdma transfer. When the transfersize is limited to 2048 bytes, the problem goes away.

OK.

Quoted 5 lines

The problem also went away with enabled interrupts because I had some debug printks added which were slowing down the transfer enough for the drive (SONY CDU-55S) to keep up and not disconnect. Got the same result by inserting udelay(100) after each 128 byte block trasnferred in pread().

Well, yeah, if you change the timing and omit to mention that, as well as changing the spinlock_irq_save/restore pairs, then it's going to be difficult for me to make sense of your results. Anyway, I'm glad that you got to the bottom of this mystery.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

When I enable interrupts during PDMA (like the removed UNSAFE macro did), the problems go away. I see an IRQ after each pread call.

These two patches are enough to make PDMA work with CD-ROM drives on 53C400(A), with IRQ enabled or not. They even improve transfer rates with HDDs because of bigger block size.

But DTC436 breaks with CDU-55S, immediately after modprobe.
1) Seems that IRQ timing is slightly different so I rewrote the wait for the host buffer to include check for CSR_GATED_53C80_IRQ. This allows some data to be transferred but
2) DTC436 likes to hang (return only 0xff from all registers - like it's not even present on the bus) on repeating CSR register reads and maybe some other actions too. This problem already appeared before in pwrite() where I added the udelay(4) workaround. Now I added udelay(100) to the waits but it still crashes sometimes (randomly after tenths or hundreds of MB).

drivers/scsi/g_NCR5380.c +2 -9

 static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
                                         struct scsi_cmnd *cmd)
 {
-	int transfersize = cmd->transfersize;
+	int transfersize = cmd->SCp.this_residual;
 
 	if (hostdata->flags & FLAG_NO_PSEUDO_DMA)
 		return 0;
 
-	/* Limit transfers to 32K, for xx400 & xx406
-	 * pseudoDMA that transfers in 128 bytes blocks.
-	 */
-	if (transfersize > 32 * 1024 && cmd->SCp.this_residual &&
-	    !(cmd->SCp.this_residual % transfersize))
-		transfersize = 32 * 1024;
-
 	/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
 	if (transfersize % 128)
 		transfersize = 0;
 
-	return transfersize;
+	return min(transfersize, G_NCR5380_DMA_MAX_SIZE);
 }
 
 /*

drivers/scsi/g_NCR5380.c +2 -0

index 9d0cfd4..797115e 100644
@@ -453,15 +453,15 @@ static inline int generic_NCR5380_pread(struct NCR5380_hostdata *hostdata,
 	int blocks = len / 128;
 	int start = 0;
 
+	hostdata->pdma_residual = 0;
+
 	NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);

drivers/scsi/g_NCR5380.c +0 -0

 		while (NCR5380_read(hostdata->c400_ctl_status) & CSR_HOST_BUF_NOT_RDY)
 			; /* FIXME - no timeout */
 

@@ -499,13 +499,13 @@ static inline int generic_NCR5380_pread(struct NCR5380_hostdata *hostdata,
 
 	if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))

drivers/scsi/g_NCR5380.c +5 -5

@@ -526,13 +526,13 @@ static inline int generic_NCR5380_pwrite(struct NCR5380_hostdata *hostdata,
 	int blocks = len / 128;
 	int start = 0;
 
+	hostdata->pdma_residual = 0;
+
 	NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
 	NCR5380_write(hostdata->c400_blk_cnt, blocks);
 	while (1) {
-		if (NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ) {
-			printk(KERN_ERR "53C400w: Got 53C80_IRQ start=%d, blocks=%d\n", start, blocks);
-			return -1;
-		}
+		if (NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ)
+			goto out_wait;
 
 		if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
 			break;

@@ -569,16 +569,15 @@ static inline int generic_NCR5380_pwrite(struct NCR5380_hostdata *hostdata,
 		start += 128;
 		blocks--;
 	}
-
+out_wait:
 	/* wait for 53C80 registers to be available */
 	while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)) {

drivers/scsi/g_NCR5380.c +5 -0

 	while (!(NCR5380_read(TARGET_COMMAND_REG) & TCR_LAST_BYTE_SENT))
 		; 	// TIMEOUT

@@ -601,6 +600,11 @@ static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
 	return min(transfersize, G_NCR5380_DMA_MAX_SIZE);
 }
 
+static int generic_NCR5380_dma_residual(struct NCR5380_hostdata *hostdata)
+{
+	return hostdata->pdma_residual;
+}
+
 /*
  *	Include the NCR5380 core code that we build our driver around	
  */

drivers/scsi/g_NCR5380.h +2 -1

index 81b22d9..08c91b7 100644
@@ -26,7 +26,8 @@
 	int c400_ctl_status; \
 	int c400_blk_cnt; \
 	int c400_host_buf; \
-	int io_width;
+	int io_width; \
+	int pdma_residual;
 
 #define NCR53C400_mem_base 0x3880
 #define NCR53C400_host_buffer 0x3900

This series removes some unused code and related comments, addresses the warnings generated by 'make W=1' and 'make C=1' and fixes a theoretical bug in the bus reset method in atari_scsi.

There's also a patch to add a missing error check during target selection. The only target I tested was a QUANTUM DAYTONA514S disk as that's all I have access to right now. Some testing with other targets would be prudent.

Michael, Ondrej, can I get you to review/test please?

Finn Thain (6):
ncr5380: Shorten host info string by removing unused option macros
ncr5380: Clean up dead code and redundant macro usage
ncr5380: Reduce #include files
ncr5380: Resolve various static checker warnings
ncr5380: Improve target selection robustness
atari_scsi: Reset DMA during bus reset only under ST-DMA lock

 drivers/scsi/NCR5380.c    |  64 ++++++++++-------------------
 drivers/scsi/NCR5380.h    |  17 +-------
 drivers/scsi/atari_scsi.c |  36 ++--------------
 drivers/scsi/g_NCR5380.c  |  45 +++++++++++++++++++-
 drivers/scsi/g_NCR5380.h  |  56 -------------------------
 drivers/scsi/mac_scsi.c   |   8 ++--
 drivers/scsi/sun3_scsi.c  |  83 +++++++++++++++++++++++++++++++++++--
 drivers/scsi/sun3_scsi.h  | 102 ----------------------------------------------
 8 files changed, 152 insertions(+), 259 deletions(-)
 delete mode 100644 drivers/scsi/g_NCR5380.h
 delete mode 100644 drivers/scsi/sun3_scsi.h

Quoted 1 line

Michael, Ondrej, can I get you to review/test please?

No regressions during testing on my Falcon both using default settings, i.e. can_queue=1 or internal queueing (can_queue=4, cmd_per_lun=2), and the legacy IDE driver.

I've seen a bus reset executed when reloading the module (bus jammed for some reason apparently), so that code path has been tested as well.

No change in the weird behaviour of my SCSI-SATA adapter, but perhaps that wasn't unexpected.

Targets: Disks Seagate ST34520W and IBM DORS-32160W, CD-ROM Plextor PX-40TS.

Tested-by Michael Schmitz <[email protected]>

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Finn" == Finn Thain <[email protected]> writes: