Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Wednesday 25 November 2015 10:04:10 Ondrej Zary wrote:
> I think that PDMA should work with 53C400A too but seems that the driver was
> never able to do it.
>
> Although there is code for port-mapped transfer in NCR5380_pread(),
> NCR53C400_register_offset is defined to 0 in the port-mapped case. The C400_
> register offsets are thus defined with negative offset:
>
> #define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8
> #define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7
> #define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6
> #define C400_HOST_BUFFER NCR53C400_register_offset-4
>
> This is probably OK for a port-mapped 53C400 (such card must have some glue
> decoding logic as the 53C400 chip itself can do memory-mapping only) because:
>
> /*
> * On NCR53C400 boards, NCR5380 registers are mapped 8 past
> * the base address.
> */
> if (overrides[current_override].board == BOARD_NCR53C400)
> instance->io_port += 8;
>
> This means that on a 53C400, first 5380 register will be at base+8 and first
> C400_ register at base.
>
> But on a 53C400A, the 5380 registers are mapped on the base address so the
> C400_ registers would be below the base, which is obviously wrong. I hope that
> PDMA will work if I fix the C400_ registers mapping.
A quick hack (breaks other chips, needs more work for proper mapping on all
chips):
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -163,7 +163,7 @@
/* Write any value to this register to start an ini mode DMA receive */
#define START_DMA_INITIATOR_RECEIVE_REG 7 /* wo */
-#define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8/* rw */
+#define C400_CONTROL_STATUS_REG 9 /* rw */
#define CSR_RESET 0x80/* wo Resets 53c400 */
#define CSR_53C80_REG 0x80/* ro 5380 registers busy */
@@ -182,13 +182,13 @@
#endif
/* Number of 128-byte blocks to be transferred */
-#define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7 /* rw */
+#define C400_BLOCK_COUNTER_REG 10/* rw */
/* Resume transfer after disconnect */
-#define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6 /* wo */
+#define C400_RESUME_TRANSFER_REG 11/* wo */
/* Access to host buffer stack */
-#define C400_HOST_BUFFER NCR53C400_register_offset-4 /* rw */
+#define C400_HOST_BUFFER 8 /* rw */
/* Note : PHASE_* macros are based on the values of the STATUS register */
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -323,7 +323,10 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
#endif
break;
case BOARD_NCR53C400A:
+ flags = FLAG_NO_DMA_FIXUP;
+#ifndef PSEUDO_DMA
flags = FLAG_NO_PSEUDO_DMA;
+#endif
ports = ncr_53c400a_ports;
break;
case BOARD_DTC3181E:
@@ -414,7 +417,8 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
if (NCR5380_init(instance, flags))
goto out_unregister;
- if (overrides[current_override].board == BOARD_NCR53C400)
+ if (overrides[current_override].board == BOARD_NCR53C400 ||
+ overrides[current_override].board == BOARD_NCR53C400A)
NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
NCR5380_maybe_reset_bus(instance);
And PDMA works on I/O mapped 53C400A (HP C2502)!
# modprobe g_NCR5380 ncr_irq=7 ncr_addr=0x280 ncr_53c400a=1
[ 1799.939856] scsi host4: Generic NCR5380/NCR53C400 SCSI, io_port 0x280,
n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize 128,
this_id 7, flags { NO_DMA_FIXUP }, options { AUTOPROBE_IRQ PSEUDO_DMA }
[ 1816.277018] scsi 4:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
PQ: 0 ANSI: 2 CCS
[ 1897.899648] sd 4:0:1:0: Attached scsi generic sg1 type 0
[ 1897.917842] sd 4:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234
MiB)
[ 1897.920872] sd 4:0:1:0: [sdb] Write Protect is off
[ 1897.924744] sd 4:0:1:0: [sdb] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 1897.967857] sdb: sdb1
[ 1897.993822] sd 4:0:1:0: [sdb] Attached SCSI disk
Nice performance improvement (although it's slower than the memory-mapped
53C400):
# hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 2 MB in 3.99 seconds = 513.57 kB/sec
And it even fixed the IRQ:
# head /proc/interrupts
CPU0
0: 151228XT-PIC timer
1: 9XT-PIC i8042
2: 0XT-PIC cascade
7:115XT-PIC NCR5380
8: 1XT-PIC rtc0
9: 0XT-PIC uhci_hcd:usb1, uhci_hcd:usb2
10: 3256XT-PIC eth0
12:136XT-PIC i8042
14: 3833XT-PIC pata_via
--
Ondrej Z
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Wed, 25 Nov 2015, Ondrej Zary wrote: > On Wednesday 25 November 2015, Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > Instead of fixing split transfers, simply forced everything > > > non-modulo-128 to PIO: > > > > [...] > > I don't have any reason to think that your card will allow part of > > a transfer to be performed with PDMA and the rest with PIO. So I don't > > really object to the patch. > > >From looking at the datasheet, I think your patch is correct. Your patch needs to be applied after mine, so if you will sign-off, I'll include it in the series with your Signed-off-by and "From:" header. > > But I don't understand the need for it either: I have no idea what > > state the driver, chip and scsi bus were in when the 126-byte PIO > > transfer failed. If the PIO transfer didn't succeed then the entire > > command should have failed. > > The patch was just a quick hack to confirm that PDMA is not completely > broken. > Now we know that it mostly works so I can investigate the partial PIO > problem. > There may not be any problem to investigate. Because this 53C80 core is embedded in other logic, it's hard to say whether or not the partial PIO algorithm could be expected to work at all. Besides, the DMA errata don't apply to this core. And large transfers will always be divisible by 128 bytes so there's very little to be gained. > [...] > > 53C400A datasheet would be great too but haven't found any. I don't have one either. -- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Wednesday 25 November 2015, Finn Thain wrote: > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > > it's HW limitation: non-modulo-128-byte transfers should use > > > > > > PIO. > > > > > > > > > > > > Adding > > > > > > transfersize = round_down(transfersize, 128); > > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are > > > > > > done using PIO, then eight 512-byte reads using PDMA and then it > > > > > > fails on a 254-byte read. First 128 bytes are read using PDMA > > > > > > and the next PDMA operation hangs waiting forever for the host > > > > > > buffer to be ready. > > > > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't > > > > > see how that is possible given round_down(126, 128) == 0. Was this > > > > > the actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with > > > > the next read?). > > > [...] > > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > > > > > Then modified NCR5380_information_transfer() to transfer the > > > > remaining data (126 bytes in this case) using PIO. It did not help, > > > > the next PDMA transfer failed too. > > > > > > > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. > > > It was always meant to cope with the need to split a transfer between > > > (P)DMA and PIO. > > > > Instead of fixing split transfers, simply forced everything > > non-modulo-128 to PIO: > > The need to split a transfer arises from early chip errata relating to DMA > and the workarounds for them (see the comments in the source). That's why > I believe that the driver was meant to be cope with this. But I don't have > any experimental evidence for it. > > I'm almost certain that these errata aren't applicable to your hardware. > So I don't have any reason to think that your card will allow part of a > transfer to be performed with PDMA and the rest with PIO. So I don't > really object to the patch. > > But I don't understand the need for it either: I have no idea what state > the driver, chip and scsi bus were in when the 126-byte PIO transfer > failed. If the PIO transfer didn't succeed then the entire command should > have failed. The patch was just a quick hack to confirm that PDMA is not completely broken. Now we know that it mostly works so I can investigate the partial PIO problem. > > --- a/drivers/scsi/g_NCR5380.c > > +++ b/drivers/scsi/g_NCR5380.c > > @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct > > scsi_cmnd *cmd) > > !(cmd->SCp.this_residual % transfersize)) > > transfersize = 32 * 1024; > > > > + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ > > Do you have a download link for this datasheet? http://bitsavers.trailing-edge.com/pdf/ncr/scsi/NCR_53C400.pdf 53C400A datasheet would be great too but haven't found any. I think that PDMA should work with 53C400A too but seems that the driver was never able to do it. Although there is code for port-mapped transfer in NCR5380_pread(), NCR53C400_register_offset is defined to 0 in the port-mapped case. The C400_ register offsets are thus defined with negative offset: #define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8 #define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7 #define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6 #define C400_HOST_BUFFER NCR53C400_register_offset-4 This is probably OK for a port-mapped 53C400 (such card must have some glue decoding logic as the 53C400 chip itself can do memory-mapping only) because: /* * On NCR53C400 boards, NCR5380 registers are mapped 8 past * the base address. */ if (overrides[current_override].board == BOARD_NCR53C400) instance->io_port += 8; This means that on a 53C400, first 5380 register will be at base+8 and first C400_ register at base. But on a 53C400A, the 5380 registers are mapped on the base address so the C400_ registers would be below the base, which is obviously wrong. I hope that PDMA will work if I fix the C400_ registers mapping. > > + if (transfersize % 128) > > + transfersize = 0; > > + > > return transfersize; > > } > > > > It seems to work and greatly improves performance: > > # hdparm -t --direct /dev/sdb > >
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tue, 24 Nov 2015, Ondrej Zary wrote: > On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > it's HW limitation: non-modulo-128-byte transfers should use > > > > > PIO. > > > > > > > > > > Adding > > > > > transfersize = round_down(transfersize, 128); > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are > > > > > done using PIO, then eight 512-byte reads using PDMA and then it > > > > > fails on a 254-byte read. First 128 bytes are read using PDMA > > > > > and the next PDMA operation hangs waiting forever for the host > > > > > buffer to be ready. > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't > > > > see how that is possible given round_down(126, 128) == 0. Was this > > > > the actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with > > > the next read?). > > [...] > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > > > Then modified NCR5380_information_transfer() to transfer the > > > remaining data (126 bytes in this case) using PIO. It did not help, > > > the next PDMA transfer failed too. > > > > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. > > It was always meant to cope with the need to split a transfer between > > (P)DMA and PIO. > > Instead of fixing split transfers, simply forced everything > non-modulo-128 to PIO: The need to split a transfer arises from early chip errata relating to DMA and the workarounds for them (see the comments in the source). That's why I believe that the driver was meant to be cope with this. But I don't have any experimental evidence for it. I'm almost certain that these errata aren't applicable to your hardware. So I don't have any reason to think that your card will allow part of a transfer to be performed with PDMA and the rest with PIO. So I don't really object to the patch. But I don't understand the need for it either: I have no idea what state the driver, chip and scsi bus were in when the 126-byte PIO transfer failed. If the PIO transfer didn't succeed then the entire command should have failed. > --- a/drivers/scsi/g_NCR5380.c > +++ b/drivers/scsi/g_NCR5380.c > @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd > *cmd) > !(cmd->SCp.this_residual % transfersize)) > transfersize = 32 * 1024; > > + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ Do you have a download link for this datasheet? > + if (transfersize % 128) > + transfersize = 0; > + > return transfersize; > } > > It seems to work and greatly improves performance: > # hdparm -t --direct /dev/sdb > > /dev/sdb: > Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec > Sounds about right... -- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > it's HW limitation: non-modulo-128-byte transfers should use PIO. > > > > > > > > Adding > > > > transfersize = round_down(transfersize, 128); > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done > > > > using PIO, then eight 512-byte reads using PDMA and then it fails on > > > > a 254-byte read. First 128 bytes are read using PDMA and the next > > > > PDMA operation hangs waiting forever for the host buffer to be > > > > ready. > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see > > > how that is possible given round_down(126, 128) == 0. Was this the > > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the > > next read?). > > When you said, the "PDMA operation hangs waiting forever", I figured that > you had hit an infinite loop in NCR5380_pread()... but now I'm lost. > > My main concern here is to confirm that I didn't break anything e.g. with > patch 24 or 41. It would be nice to know that this hang is not the result > of a new bug. > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > Then modified NCR5380_information_transfer() to transfer the remaining > > data (126 bytes in this case) using PIO. It did not help, the next PDMA > > transfer failed too. > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. It > was always meant to cope with the need to split a transfer between (P)DMA > and PIO. Instead of fixing split transfers, simply forced everything non-modulo-128 to PIO: --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd *cmd) !(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; } It seems to work and greatly improves performance: # hdparm -t --direct /dev/sdb /dev/sdb: Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015 13:03:17 Ondrej Zary wrote: > On Tuesday 24 November 2015, Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > it's HW limitation: non-modulo-128-byte transfers should use PIO. > > > > > > > > > > Adding > > > > > transfersize = round_down(transfersize, 128); > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done > > > > > using PIO, then eight 512-byte reads using PDMA and then it fails on > > > > > a 254-byte read. First 128 bytes are read using PDMA and the next > > > > > PDMA operation hangs waiting forever for the host buffer to be > > > > > ready. > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see > > > > how that is possible given round_down(126, 128) == 0. Was this the > > > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the > > > next read?). > > > > When you said, the "PDMA operation hangs waiting forever", I figured that > > you had hit an infinite loop in NCR5380_pread()... but now I'm lost. > > The first 128-byte PDMA ended successfully (ignoring what happened to the > remaining 126 bytes), then a next request for 254 bytes came. This resulted > in a new 128-byte PDMA and that hanged (in one of its possibly infinite loops > without a timeout). > > > My main concern here is to confirm that I didn't break anything e.g. with > > patch 24 or 41. It would be nice to know that this hang is not the result > > of a new bug. > > PDMA was already broken before so it's hard to tell. I can try to modify > the unpatched driver to see if PDMA is broken the same way. Just tested the driver without your patches and it's broken exactly the same way. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015, Finn Thain wrote:
>
> On Tue, 24 Nov 2015, Ondrej Zary wrote:
>
> > On Tuesday 24 November 2015, Finn Thain wrote:
> > >
> > > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > > it's HW limitation: non-modulo-128-byte transfers should use PIO.
> > > >
> > > > Adding
> > > > transfersize = round_down(transfersize, 128);
> > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > > >
> > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done
> > > > using PIO, then eight 512-byte reads using PDMA and then it fails on
> > > > a 254-byte read. First 128 bytes are read using PDMA and the next
> > > > PDMA operation hangs waiting forever for the host buffer to be
> > > > ready.
> > > >
> > >
> > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see
> > > how that is possible given round_down(126, 128) == 0. Was this the
> > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
> >
> > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the
> > next read?).
>
> When you said, the "PDMA operation hangs waiting forever", I figured that
> you had hit an infinite loop in NCR5380_pread()... but now I'm lost.
The first 128-byte PDMA ended successfully (ignoring what happened to the
remaining 126 bytes), then a next request for 254 bytes came. This resulted
in a new 128-byte PDMA and that hanged (in one of its possibly infinite loops
without a timeout).
> My main concern here is to confirm that I didn't break anything e.g. with
> patch 24 or 41. It would be nice to know that this hang is not the result
> of a new bug.
PDMA was already broken before so it's hard to tell. I can try to modify
the unpatched driver to see if PDMA is broken the same way.
> > The next read was also 254 bytes so another 128-byte PDMA transfer.
> >
> > Then modified NCR5380_information_transfer() to transfer the remaining
> > data (126 bytes in this case) using PIO. It did not help, the next PDMA
> > transfer failed too.
> >
>
> AFAICT, no change to NCR5380_information_transfer() should be needed. It
> was always meant to cope with the need to split a transfer between (P)DMA
> and PIO.
>
> If the target is expecting the remaining 126 bytes, it will keep the bus
> in DATA OUT phase, and the next iteration of the loop
> while ((cmd = hostdata->connected)) { }
> will call NCR5380_transfer_pio() for the remaining bytes. If the target
> never asserts REQ, that transfer will never happen, but then the command
> should timeout and get aborted, to handle the possibility that a "PDMA
> operation hangs waiting forever".
Thanks for explanation.
> A protocol analyzer would be useful to debug this. I get a lot of value
> from a bus terminator block that has LEDs for the various control signals.
> Failing that, you might need to place,
> #define NDEBUG (NDEBUG_INFORMATION | NDEBUG_HANDSHAKE | NDEBUG_PIO |
> NDEBUG_DMA | NDEBUG_MAIN)
> at the top of g_NCR5380.c.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tue, 24 Nov 2015, Ondrej Zary wrote:
> On Tuesday 24 November 2015, Finn Thain wrote:
> >
> > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> >
> > >
> > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > it's HW limitation: non-modulo-128-byte transfers should use PIO.
> > >
> > > Adding
> > > transfersize = round_down(transfersize, 128);
> > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > >
> > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done
> > > using PIO, then eight 512-byte reads using PDMA and then it fails on
> > > a 254-byte read. First 128 bytes are read using PDMA and the next
> > > PDMA operation hangs waiting forever for the host buffer to be
> > > ready.
> > >
> >
> > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see
> > how that is possible given round_down(126, 128) == 0. Was this the
> > actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
>
> No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the
> next read?).
When you said, the "PDMA operation hangs waiting forever", I figured that
you had hit an infinite loop in NCR5380_pread()... but now I'm lost.
My main concern here is to confirm that I didn't break anything e.g. with
patch 24 or 41. It would be nice to know that this hang is not the result
of a new bug.
> The next read was also 254 bytes so another 128-byte PDMA transfer.
>
> Then modified NCR5380_information_transfer() to transfer the remaining
> data (126 bytes in this case) using PIO. It did not help, the next PDMA
> transfer failed too.
>
AFAICT, no change to NCR5380_information_transfer() should be needed. It
was always meant to cope with the need to split a transfer between (P)DMA
and PIO.
If the target is expecting the remaining 126 bytes, it will keep the bus
in DATA OUT phase, and the next iteration of the loop
while ((cmd = hostdata->connected)) { }
will call NCR5380_transfer_pio() for the remaining bytes. If the target
never asserts REQ, that transfer will never happen, but then the command
should timeout and get aborted, to handle the possibility that a "PDMA
operation hangs waiting forever".
A protocol analyzer would be useful to debug this. I get a lot of value
from a bus terminator block that has LEDs for the various control signals.
Failing that, you might need to place,
#define NDEBUG (NDEBUG_INFORMATION | NDEBUG_HANDSHAKE | NDEBUG_PIO | NDEBUG_DMA
| NDEBUG_MAIN)
at the top of g_NCR5380.c.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015, Finn Thain wrote: > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot process > > less than 128 bytes. In fact, 53C400 datasheet says that it's HW > > limitation: non-modulo-128-byte transfers should use PIO. > > > > Adding > > transfersize = round_down(transfersize, 128); > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using > > PIO, then eight 512-byte reads using PDMA and then it fails on a > > 254-byte read. First 128 bytes are read using PDMA and the next PDMA > > operation hangs waiting forever for the host buffer to be ready. > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see how > that is possible given round_down(126, 128) == 0. Was this the actual > 'len' argument to NCR5380_pread() in g_NCR5380.c? No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the next read?). The next read was also 254 bytes so another 128-byte PDMA transfer. Then modified NCR5380_information_transfer() to transfer the remaining data (126 bytes in this case) using PIO. It did not help, the next PDMA transfer failed too. > BTW, I presume that FLAG_NO_DMA_FIXUPS was set (which is the case if you > pass ncr_53c400=1 option with modprobe). Otherwise you could see PDMA IO > sizes like 127 etc. Yes, the flag was set. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Mon, 23 Nov 2015, Ondrej Zary wrote: > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot process > less than 128 bytes. In fact, 53C400 datasheet says that it's HW > limitation: non-modulo-128-byte transfers should use PIO. > > Adding > transfersize = round_down(transfersize, 128); > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using > PIO, then eight 512-byte reads using PDMA and then it fails on a > 254-byte read. First 128 bytes are read using PDMA and the next PDMA > operation hangs waiting forever for the host buffer to be ready. > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see how that is possible given round_down(126, 128) == 0. Was this the actual 'len' argument to NCR5380_pread() in g_NCR5380.c? BTW, I presume that FLAG_NO_DMA_FIXUPS was set (which is the case if you pass ncr_53c400=1 option with modprobe). Otherwise you could see PDMA IO sizes like 127 etc. -- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Sunday 22 November 2015 00:32:31 Finn Thain wrote:
>
> On Sat, 21 Nov 2015, Ondrej Zary wrote:
>
> > On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
> >
> > >
> > > I gather that your setup here is a QUANTUM LP240S target with Domex
> > > 3181 (DTC-436) card and g_NCR5380 module. I've been testing a similar
> > > setup: QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and
> > > dmx3191d module. In both setups PIO is used exclusively, no IRQ is
> > > used, and FLAG_DTC3181E is set. I didn't see any issues in my tests,
> > > so your results are surprising.
> >
> > I agree that the results are surprising. Even tried 2.4 kernels (Debian
> > 3.1) and even 2.2 (Debian 3.0) and nothing worked. HW is fine - the
> > drive is accessible in Windows 98 (with Domex driver installed).
>
> That's good to know (and very thorough).
>
> >
> > Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with
> > only two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ
> > hardwired to 7.
> >
> > # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
> >
> > [ 1245.919223] scsi2 : interrupts not enabled. for better interactive
> > performance,
> > [ 1245.919326] scsi2 : please jumper the board for a free IRQ.
> > [ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> > n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> > 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250,
> > options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> > [ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X
> > 4.6 PQ: 0 ANSI: 2 CCS
> > [ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
> > [ 1248.420856] 53C400r: no 53C80 gated irq after transfer
> > [ 1248.420948] 53C400r: no end dma signal
> > [ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
> >
> > Seems that the PSEUDO_DMA is broken.
>
> That's been my experience with mac_scsi also (going back 10 years). I'm
> told that it used to work in v2.2. PIO was always usable though hopelessly
> slow.
>
> I haven't yet done any work on the PDMA problem with mac_scsi because
> crashing bugs and the forked core driver seemed to be the more pressing
> problems. And resolving the fork has implications for all of the DMA
> variations anyway.
PDMA seems to be broken in multiple ways. NCR5380_pread cannot process less
than 128 bytes. In fact, 53C400 datasheet says that it's HW limitation:
non-modulo-128-byte transfers should use PIO.
Adding
transfersize = round_down(transfersize, 128);
to generic_NCR5380_dma_xfer_len() improves the situation a bit.
After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using PIO,
then eight 512-byte reads using PDMA and then it fails on a 254-byte read.
First 128 bytes are read using PDMA and the next PDMA operation hangs waiting
forever for the host buffer to be ready.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Sat, 21 Nov 2015, Ondrej Zary wrote:
> On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
>
> >
> > I gather that your setup here is a QUANTUM LP240S target with Domex
> > 3181 (DTC-436) card and g_NCR5380 module. I've been testing a similar
> > setup: QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and
> > dmx3191d module. In both setups PIO is used exclusively, no IRQ is
> > used, and FLAG_DTC3181E is set. I didn't see any issues in my tests,
> > so your results are surprising.
>
> I agree that the results are surprising. Even tried 2.4 kernels (Debian
> 3.1) and even 2.2 (Debian 3.0) and nothing worked. HW is fine - the
> drive is accessible in Windows 98 (with Domex driver installed).
That's good to know (and very thorough).
>
> Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with
> only two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ
> hardwired to 7.
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 1245.919223] scsi2 : interrupts not enabled. for better interactive
> performance,
> [ 1245.919326] scsi2 : please jumper the board for a free IRQ.
> [ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250,
> options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 1248.420856] 53C400r: no 53C80 gated irq after transfer
> [ 1248.420948] 53C400r: no end dma signal
> [ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
>
> Seems that the PSEUDO_DMA is broken.
That's been my experience with mac_scsi also (going back 10 years). I'm
told that it used to work in v2.2. PIO was always usable though hopelessly
slow.
I haven't yet done any work on the PDMA problem with mac_scsi because
crashing bugs and the forked core driver seemed to be the more pressing
problems. And resolving the fork has implications for all of the DMA
variations anyway.
> After adding FLAG_NO_PSEUDO_DMA:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 67.974362] scsi2 : interrupts not enabled. for better interactive
> performance,
> [ 67.974463] scsi2 : please jumper the board for a free IRQ.
> [ 67.974526] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NCR53C400 NO_PSEUDO_DMA }, USLEEP_POLL 3,
> USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 68.432728] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 70.258258] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 70.277265] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234
> MiB)
> [ 70.482252] sd 2:0:1:0: [sdb] Write Protect is off
> [ 70.482335] sd 2:0:1:0: [sdb] Mode Sense: 8b 00 00 08
> [ 70.889646] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [ 73.159513] sdb: sdb1
> [ 74.617099] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> Yeah, first success! I can even mount the filesystem, although it takes ages
> (a minute) and these messages:
> [ 160.872074] sd 2:0:1:0: [sdb] aborting command
> [ 161.816083] sd 2:0:1:0: [sdb] aborting command
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> [ 244.840075] sd 2:0:1:0: [sdb] aborting command
> [ 248.824078] sd 2:0:1:0: [sdb] aborting command
> [ 293.864069] sd 2:0:1:0: [sdb] aborting command
> [ 297.824075] sd 2:0:1:0: [sdb] aborting command
> [ 319.765020] blk_update_request: critical target error, dev sdb, sector 0
> [ 319.972994] blk_update_request: critical target error, dev sdb, sector 0
> Timing O_DIRECT disk reads: 2 MB in 105.26 seconds = 19.46 kB/sec
>
>
>
> With your patches (and adding FLAG_NO_PSEUDO_DMA), modprobe is slower but
> mount faster (4 seconds) and then works better:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 130.126185] scsi2 : interrupts not enabled. for better interactive
> performance,
> [ 130.126284] scsi2 : please jumper the board for a free IRQ.
> [ 130.126347] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 145.221755] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 220.629912] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 220.651400] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234
> MiB)
> [ 220.654061] sd 2:0:1:0: [sdb] Write Protect is off
> [ 220.659344] sd 2:0:1:0: [sdb] Write cache: enabled, read
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Saturday 21 November 2015 14:01:39 Ondrej Zary wrote:
> On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
> >
> > Hi Ondrej,
> >
> > On Fri, 20 Nov 2015, Ondrej Zary wrote:
> >
> > > On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> > > >
> > > >
> > > > 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?
> > >
[...]
> > >
> >
> > Thanks for these test results! It looks like READ(10) commands don't work.
> > I don't know the cause of the failures but it appears to be an old bug.
> > Did you find any regression?
> >
> > I gather that your setup here is a QUANTUM LP240S target with Domex 3181
> > (DTC-436) card and g_NCR5380 module. I've been testing a similar setup:
> > QUANTUM LPS540S target with a Domex 3191D (DTC-536) card and dmx3191d
> > module. In both setups PIO is used exclusively, no IRQ is used, and
> > FLAG_DTC3181E is set. I didn't see any issues in my tests, so your results
> > are surprising.
>
> I agree that the results are surprising. Even tried 2.4 kernels (Debian 3.1)
> and even 2.2 (Debian 3.0) and nothing worked.
> HW is fine - the drive is accessible in Windows 98 (with Domex driver
> installed).
>
> Now testing the Canon FG2-5202 controller - a simple 8-bit ISA card with only
> two chips: NCR 53C400 and 74LS245. It's memory mapped, IRQ hardwired to 7.
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 1245.919223] scsi2 : interrupts not enabled. for better interactive
> performance,
> [ 1245.919326] scsi2 : please jumper the board for a free IRQ.
> [ 1245.919389] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_WAITLONG 1250,
> options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 1246.376738] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 1248.202198] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 1248.420856] 53C400r: no 53C80 gated irq after transfer
> [ 1248.420948] 53C400r: no end dma signal
> [ 1248.422459] sd 2:0:1:0: [sdb] Sector size 0 reported, assuming 512.
>
> Seems that the PSEUDO_DMA is broken. After adding FLAG_NO_PSEUDO_DMA:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 67.974362] scsi2 : interrupts not enabled. for better interactive
> performance,
> [ 67.974463] scsi2 : please jumper the board for a free IRQ.
> [ 67.974526] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NCR53C400 NO_PSEUDO_DMA }, USLEEP_POLL 3,
> USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA NCR53C400 }
> [ 68.432728] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 70.258258] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [ 70.277265] sd 2:0:1:0: [sdb] 479350 512-byte logical blocks: (245 MB/234
> MiB)
> [ 70.482252] sd 2:0:1:0: [sdb] Write Protect is off
> [ 70.482335] sd 2:0:1:0: [sdb] Mode Sense: 8b 00 00 08
> [ 70.889646] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [ 73.159513] sdb: sdb1
> [ 74.617099] sd 2:0:1:0: [sdb] Attached SCSI disk
>
> Yeah, first success! I can even mount the filesystem, although it takes ages
> (a minute) and these messages:
> [ 160.872074] sd 2:0:1:0: [sdb] aborting command
> [ 161.816083] sd 2:0:1:0: [sdb] aborting command
>
> # hdparm -t --direct /dev/sdb
>
> /dev/sdb:
> [ 244.840075] sd 2:0:1:0: [sdb] aborting command
> [ 248.824078] sd 2:0:1:0: [sdb] aborting command
> [ 293.864069] sd 2:0:1:0: [sdb] aborting command
> [ 297.824075] sd 2:0:1:0: [sdb] aborting command
> [ 319.765020] blk_update_request: critical target error, dev sdb, sector 0
> [ 319.972994] blk_update_request: critical target error, dev sdb, sector 0
> Timing O_DIRECT disk reads: 2 MB in 105.26 seconds = 19.46 kB/sec
>
>
>
> With your patches (and adding FLAG_NO_PSEUDO_DMA), modprobe is slower but
> mount faster (4 seconds) and then works better:
>
> # modprobe g_NCR5380_mmio ncr_irq=255 ncr_addr=0xd8000 ncr_53c400=1
>
> [ 130.126185] scsi2 : interrupts not enabled. for better interactive
> performance,
> [ 130.126284] scsi2 : please jumper the board for a free IRQ.
> [ 130.126347] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NO_PSEUDO_DMA }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 145.221755] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI:
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
>
> Hi Ondrej,
>
> On Fri, 20 Nov 2015, Ondrej Zary wrote:
>
> > On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> > >
> > >
> > > 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:2D 0040 060 2 0x
> > [ 480.110671] Workqueue: events_unbound async_run_entry_fn
> > [ 480.110999] cf9e8780 0046 2eff25f7 0040 c117f111 2ee82733
> > 0040 0016fec4
> > [ 480.112390] cfaa6000 7fff c139c7d2 c139c504
> > 7fff c139d9d3
> > [ 480.113661] 0040 cfaa5cfc c106f460 00161108 c648
> > 2106dcce 0040
> > [ 480.114893] Call Trace:
> > [ 480.115124] [] ? blk_queue_bio+0x1e8/0x1fb
> > [ 480.115344] [] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 480.115564] [] ? schedule+0x5b/0x67
> > [ 480.115794] [] ? schedule_timeout+0x13/0xc5
> > [ 480.116007] [] ? timekeeping_get_ns+0x10/0x69
> > [ 480.116406] [] ? bit_wait_io_timeout+0x3d/0x3d
> > [ 480.116636] [] ? ktime_get+0x38/0x48
> > [ 480.116843] [] ? io_schedule_timeout+0x83/0xd7
> > [ 480.117062] [] ? bit_wait_io+0x21/0x26
> > [ 480.117256] [] ? __wait_on_bit+0x2f/0x5a
> > [ 480.117486] [] ? blkdev_readpages+0x15/0x15
> > [ 480.117704] [] ? wait_on_page_bit+0x57/0x5e
> > [ 480.117942] [] ? wake_atomic_t_function+0x2a/0x2a
> > [ 480.118151] [] ? wait_on_page_read+0xf/0x2a
> > [ 480.118373] [] ? do_read_cache_page+0x8e/0x116
> > [ 480.118587] [] ? blkdev_readpages+0x15/0x15
> > [ 480.118809] [] ? read_cache_page+0x14/0x18
> > [ 480.119008] [] ? read_dev_sector+0x25/0x57
> > [ 480.119222] [] ? adfspart_check_ICS+0x30/0x1ac
> > [ 480.119438] [] ? vsnprintf+0x78/0x25d
> > [ 480.119671] [] ? snprintf+0x16/0x18
> > [ 480.119874] [] ? check_partition+0xd7/0x165
> > [ 480.120253] [] ? rescan_partitions+0x95/0x283
> > [ 480.120443] [] ? scsi_block_when_processing_errors+0x13/0xae
> > [ 480.120693] [] ? mutex_lock+0x9/0x21
> > [ 480.120915] [] ? __blkdev_get+0x155/0x2f6
> > [ 480.121133] [] ? blkdev_get+0x148/0x258
> > [ 480.121350] [] ? unlock_new_inode+0x36/0x3c
> > [ 480.121570] [] ? bdget+0xdc/0xe6
> > [ 480.121761] [] ? add_disk+0x221/0x368
> > [ 480.121996] [] ? sd_probe_async+0xed/0x157
> > [ 480.122214] [] ? async_run_entry
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
Hi Ondrej,
On Fri, 20 Nov 2015, Ondrej Zary wrote:
> On Friday 20 November 2015 02:41:19 Finn Thain wrote:
> >
> >
> > 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:2D 0040 060 2 0x
> [ 480.110671] Workqueue: events_unbound async_run_entry_fn
> [ 480.110999] cf9e8780 0046 2eff25f7 0040 c117f111 2ee82733
> 0040 0016fec4
> [ 480.112390] cfaa6000 7fff c139c7d2 c139c504
> 7fff c139d9d3
> [ 480.113661] 0040 cfaa5cfc c106f460 00161108 c648
> 2106dcce 0040
> [ 480.114893] Call Trace:
> [ 480.115124] [] ? blk_queue_bio+0x1e8/0x1fb
> [ 480.115344] [] ? bit_wait_io_timeout+0x3d/0x3d
> [ 480.115564] [] ? schedule+0x5b/0x67
> [ 480.115794] [] ? schedule_timeout+0x13/0xc5
> [ 480.116007] [] ? timekeeping_get_ns+0x10/0x69
> [ 480.116406] [] ? bit_wait_io_timeout+0x3d/0x3d
> [ 480.116636] [] ? ktime_get+0x38/0x48
> [ 480.116843] [] ? io_schedule_timeout+0x83/0xd7
> [ 480.117062] [] ? bit_wait_io+0x21/0x26
> [ 480.117256] [] ? __wait_on_bit+0x2f/0x5a
> [ 480.117486] [] ? blkdev_readpages+0x15/0x15
> [ 480.117704] [] ? wait_on_page_bit+0x57/0x5e
> [ 480.117942] [] ? wake_atomic_t_function+0x2a/0x2a
> [ 480.118151] [] ? wait_on_page_read+0xf/0x2a
> [ 480.118373] [] ? do_read_cache_page+0x8e/0x116
> [ 480.118587] [] ? blkdev_readpages+0x15/0x15
> [ 480.118809] [] ? read_cache_page+0x14/0x18
> [ 480.119008] [] ? read_dev_sector+0x25/0x57
> [ 480.119222] [] ? adfspart_check_ICS+0x30/0x1ac
> [ 480.119438] [] ? vsnprintf+0x78/0x25d
> [ 480.119671] [] ? snprintf+0x16/0x18
> [ 480.119874] [] ? check_partition+0xd7/0x165
> [ 480.120253] [] ? rescan_partitions+0x95/0x283
> [ 480.120443] [] ? scsi_block_when_processing_errors+0x13/0xae
> [ 480.120693] [] ? mutex_lock+0x9/0x21
> [ 480.120915] [] ? __blkdev_get+0x155/0x2f6
> [ 480.121133] [] ? blkdev_get+0x148/0x258
> [ 480.121350] [] ? unlock_new_inode+0x36/0x3c
> [ 480.121570] [] ? bdget+0xdc/0xe6
> [ 480.121761] [] ? add_disk+0x221/0x368
> [ 480.121996] [] ? sd_probe_async+0xed/0x157
> [ 480.122214] [] ? async_run_entry_fn+0x2c/0xad
> [ 480.122437] [] ? process_one_work+0x130/0x21f
> [ 480.122639] [] ? worker_thread+0x18a/0x247
> [ 480.122854] [] ? process_scheduled_works+0x1d/0x1d
> [ 480.123069] [] ? kthread+0x7c/0x81
> [ 480.123288] [] ? ret_from_kernel_th
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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:2D 0040 060 2 0x
[ 480.110671] Workqueue: events_unbound async_run_entry_fn
[ 480.110999] cf9e8780 0046 2eff25f7 0040 c117f111 2ee82733 0040
0016fec4
[ 480.112390] cfaa6000 7fff c139c7d2 c139c504 7fff
c139d9d3
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Friday 20 November 2015, Geert Uytterhoeven wrote: > On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary > 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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary
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 -- ge...@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-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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] modprobeD 001a 0 1957 1950 0x
> > [ 240.108790] ce0fad00 0086 53881781 001a c1525f88 4edbe39c
> > 001a 04ac33e5
> > [ 240.109246] ccd54000 d204b280 c139c504
> > c104416d
> > [ 240.109699] ce0fad00 c1054a45 c151fd8c c151fd8c d204b280
> > ccd6d100
> > [ 240.110156] Call Trace:
> > [ 240.110295] [] ? schedule+0x5b/0x67
> > [ 240.110430] [] ? async_synchronize_cookie_domain+0x73/0x9f
> > [ 240.110569] [] ? abort_exclusive_wait+0x6e/0x6e
> > [ 240.110699] [] ? do_init_module+0xa4/0x1a3
> > [ 240.110824] [] ? load_module+0x14de/0x18ca
> > [ 240.110948] [] ? SyS_finit_module+0x47/0x56
> > [ 240.111068] [] ? 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:
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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] modprobeD 001a 0 1957 1950 0x > > [ 240.108790] ce0fad00 0086 53881781 001a c1525f88 4edbe39c > > 001a 04ac33e5 > > [ 240.109246] ccd54000 d204b280 c139c504 > > c104416d > > [ 240.109699] ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 > > ccd6d100 > > [ 240.110156] Call Trace: > > [ 240.110295] [] ? schedule+0x5b/0x67 > > [ 240.110430] [] ? async_synchronize_cookie_domain+0x73/0x9f > > [ 240.110569] [] ? abort_exclusive_wait+0x6e/0x6e > > [ 240.110699] [] ? do_init_module+0xa4/0x1a3 > > [ 240.110824] [] ? load_module+0x14de/0x18ca > > [ 240.110948] [] ? SyS_finit_module+0x47/0x56 > > [ 240.111068] [] ? 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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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] modprobeD 001a 0 1957 1950 0x
> [ 240.108790] ce0fad00 0086 53881781 001a c1525f88 4edbe39c
> 001a 04ac33e5
> [ 240.109246] ccd54000 d204b280 c139c504
> c104416d
> [ 240.109699] ce0fad00 c1054a45 c151fd8c c151fd8c d204b280
> ccd6d100
> [ 240.110156] Call Trace:
> [ 240.110295] [] ? schedule+0x5b/0x67
> [ 240.110430] [] ? async_synchronize_cookie_domain+0x73/0x9f
> [ 240.110569] [] ? abort_exclusive_wait+0x6e/0x6e
> [ 240.110699] [] ? do_init_module+0xa4/0x1a3
> [ 240.110824] [] ? load_module+0x14de/0x18ca
> [ 240.110948] [] ? SyS_finit_module+0x47/0x56
> [ 240.111068] [] ? 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] modprobeD 001a 0 1957 1950 0x
> [ 360.108787] ce0fad00 0086 53881781 001a c1525f88 4edbe39c
> 001a 04ac3
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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] modprobeD 001a 0 1957 1950 0x
[ 240.108790] ce0fad00 0086 53881781 001a c1525f88 4edbe39c 001a
04ac33e5
[ 240.109246] ccd54000 d204b280 c139c504
c104416d
[ 240.109699] ce0fad00 c1054a45 c151fd8c c151fd8c d204b280
ccd6d100
[ 240.110156] Call Trace:
[ 240.110295] [] ? schedule+0x5b/0x67
[ 240.110430] [] ? async_synchronize_cookie_domain+0x73/0x9f
[ 240.110569] [] ? abort_exclusive_wait+0x6e/0x6e
[ 240.110699] [] ? do_init_module+0xa4/0x1a3
[ 240.110824] [] ? load_module+0x14de/0x18ca
[ 240.110948] [] ? SyS_finit_module+0x47/0x56
[ 240.111068] [] ? 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
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
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-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
